まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:cloud

これらの記事の続きです:
IBM Cloud の無料版 Kubernetes サービスを使ってみた(1)
IBM Cloud の無料版 Kubernetes サービスを使ってみた(2)


IBM Cloud の Kubernetes サービスを使って、無料のワーカーノードにアプリケーションをデプロイして、(いったん)削除する所までを紹介しました。最終回である今回は実際にアプリケーションにアクセスしたり、デプロイしたアプリケーションをスケールさせてみたり、外部(インターネット)に公開してみたりします。

今回の作業も基本的にすべて Web Terminal から行います。というわけで、まず Web Terminal を起動します:
2019041109


改めてアプリケーションをデプロイします。が、今回は後述の RC(ReplicatoinController) としてデプロイするため、デプロイ用のファイル(rc.yaml)を作成します:
apiVersion: v1
kind: ReplicationController
metadata:
  name: kubernetes-bootcamp
spec:
  replicas: 1
  selector:
    app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: myk8x
        image: gcr.io/google-samples/kubernetes-bootcamp:v1
        ports:
        - containerPort: 8080

デプロイ時にはこのファイル(rc.yaml)を指定して、以下のコマンドを実行します:
$ kubectl create -f rc.yaml
replicationcontroller/kubernetes-bootcamp created

このコマンドで前回とほぼ同様に kubernetes-bootcamp アプリケーションを1つのポッドにデプロイします。また app: web というセレクターを指定していますが、この後で使います。

この時点で kubernetes-bootcamp アプリケーションが1つのポッドにデプロイされます。一応ポッドと、そして(詳しくは後述の)サービスの状態を確認しておきます(緑字はコメント):
$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-jfswt   1/1     Running   0          41s  1ポッド

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.21.0.1   <none>        443/TCP   3d21h  ここはクラスタサービスなので無視、つまり起動したサービスなし

この時点で1つのポッドにアプリケーションがデプロイされたことが確認できました。しかしこのポッドはまだコンテナの外部からアクセスすることができません。コンテナの外部からでもアクセスできるように紐付けるサービスを作成します。

作成するサービスのための設定ファイル(service.json)を以下の内容で用意します:
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "web"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 8080,
                "nodePort": 30000
            }
        ],
        "type" : "NodePort"
    }
}

"spec" 内で app:web のラベルをセレクターに指定しています。これが先程作成したデプロイメント時の指定内容となっていて、kubernetes-bootcamp に紐づく形になります。また 8080 番ポートをターゲットに接続し、80 番ポートで公開する、という指定も行い、"my-service" という名前でサービスを作るよう指示しています。

ではこのファイル(service.json)を使ってサービスを作成します。同時に再びポッドとサービスの内容を照会してみます:
$ kubectl create -f service.json
service/my-service created

$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-jfswt   1/1     Running   0          13m  1ポッド

$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   172.21.0.1   <none>        443/TCP   3d21h
my-service   NodePort    172.21.30.70 <none>        80:30000/TCP   94s 追加されたサービス

サービスの追加に成功しました。またその追加されたサービスはクラスター内の内部 IP アドレスである 172.21.30.70:80 上で稼働していることがわかりました。

ではこのサービスを使ってアプリケーションにアクセスしてします:
$ curl http://172.21.30.70/
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-jfswt | v=1

アプリケーションにコンテナ外部からアクセスでき、正しく動作していることも確認できました。ただし、この時点ではまだあくまで内部ネットワーク内からのアクセスが確認できただけで、まだインターネットからはアクセスできません(後述します)。


コンテナの外部からアプリケーションにアクセスできることは確認できましたが、せっかくなので Kubernetes っぽい挙動もさせてみます。現在1つのポッドで動作しているこのアプリケーションをスケールアウトして複数の(今回は2つの)ポッドで起動するようにしてみます:
$ kubectl scale -f rc.yaml --replicas=2
replicationcontroller/kubernetes-bootcamp scaled

この状態で再びポッドとサービスの状態を確認します。ポッドが2つになっていることがわかります。(一方、サービスは何も変わっていません):
$ kubectl get pod
NAME                        READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-kqkhp   1/1     Running   0          14s スケールアウトして新しく増えたポッド
kubernetes-bootcamp-jfswt   1/1     Running   0          109s

$ kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   172.21.0.1      <none>        443/TCP        3d23h
my-service   NodePort    172.21.30.70    <none>        80:30000/TCP   5m16s

ではこのアプリケーションをインターネットに公開してみます。以下のコマンドを実行します:
$ kubectl expose rc kubernetes-bootcamp --type=NodePort --name=web
service/web exposed

$ kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   172.21.0.1       <none>        443/TCP          4d20h
my-service   NodePort    172.21.199.105   <none>        80:30000/TCP     4m30s
web          NodePort    172.21.64.253    <none>        8080:30703/TCP   4m9s

"web" という名称のサービスが追加され、kubernetes-bootcamp の rc が expose(外部公開)されました。公開先のポート番号が 30703 になっていることも確認できます。

また、公開先の IP アドレスはワーカーノードのパブリック IP アドレスになっています。ダッシュボードから確認するか、または以下のコマンドを実行します:
2019041601
$ ibmcloud cs workers mycluster (最後のパラメーターはクラスタ名)

ID                                                 Public IP       Private IP       Machine Type   State    Status   Zone    Version   
kube-mel01-pa351ddd2ea19441a689a49159389f9d45-w1   168.1.149.201   10.118.243.103   free           normal   Ready    mel01   1.12.7_1548*


この例だと、パブリック IP アドレスが 168.1.149.201 となっているので、この 30703 番ポートに対してウェブブラウザでアクセスし、期待通りの結果になることを確認します:
2019041602


最後に、サービスとポッドを削除する場合は以下のコマンドを実行します:
$ kubectl delete svc web
service "web" deleted

$ kubectl delete -f service.json
service "my-service" deleted

$ kubectl delete -f rc.yaml
replicationcontroller "kubernetes-bootcamp" deleted


IBM Cloud の(無料の)Kubernetes サービスを使って、アプリケーションのデプロイ、スケール、動作確認、ウェブ公開、といった一連の作業ができることが確認できました。すでに Kubernetes 環境を手元に持っているような人であればともかく、これから Kubernetes を使ってみようと思う人にとっては面倒な準備作業も不要で気軽に始められて、スケールやウェブ公開といった一通りの作業ができるところまで使える環境としてとても便利だと思いました。





この記事の続きです。

IBM Cloud の無料版 Kubernetes サービスで、Kubernetes クラスタを立ち上げる所までを紹介しました。 今回は(ベータ版の)Web Terminal 機能を使って、この Kubernetes サービスの状態を確認したり、アプリケーションをデプロイしてみます。

IBM Cloud を操作する場合、一般的には ibmcloud コマンドを使います。また Kubernetes クラスタの状態を確認する場合、一般的には kubectl コマンドを使うことが多いと思っています。普段使っているマシンに ibmcloud コマンドや kubectl コマンドがすでにセットアップされているような場合はそれらのコマンドを使えばいいのですが、まだ導入されていないようなケースでは別途セットアップしてから利用する必要があります。 今回紹介する Web Terminal はそういった導入をしなくてもウェブブラウザ内のコンソールから ibmcloud コマンドや kubectl コマンドを使って操作できる方法です。現時点(2019/04/15)でベータ版なので今後どういう形になるかわかりませんが、使ってみて便利だったので紹介させていただくことにしました。

では以下に実際の手順を紹介します。まず前回の記事の内容が正しく実行されて、"mycluster" という名称の Kubernetes クラスタが稼働している状態になっていることを確認します:
2019041107


"Worker Nodes" タブでワーカーノード(今回は1つ)が正しく動いている点も確認します(この画面では IP アドレスをモザイクにしていますが、実際にはモザイクなしに表示されます):
2019041108


ではまずはこのワーカーノードの状態を Web Terminal からも確認してみます。画面内の "Web Terminal" と書かれたボタンをクリックします:
2019041109


最初にクリックした時だけ、「Kubernetes Terminal をインストールする」という確認のダイアログが表示されます。「Install」ボタンをクリックすると Kubernetes Terminal がインストールされます(少し時間がかかります、十数秒くらい?):
2019041110


(Kubernetes Terminal をインストールした場合は十数秒程度待って)改めて "Web Terminal" ボタンをクリックします。するとブラウザ画面下部からターミナルが現れます:
2019041111


このターミナルのプロンプトで、画面内に書かれたセットアップ手順を順に実行していきます。ibmcloud コマンドは特にインストールしていませんが、この Web Terminal 内では導入済みなので普通にそのまま使うことができます(赤字はコメント):
2019041112
$ ibmcloud login -a https://cloud.ibm.com ログイン

$ ibmcloud ks region-set ap-south サービスのリージョンを(作成したリージョンに)指定

$ ibmcloud ks cluster-config mycluster Kubernetes の環境設定用ファイルを生成してダウンロード

最後のコマンドを実行すると KUBECONFIG 環境変数を設定するためのコマンドが表示されます。そこに書かれた内容をそのままコピー&ペーストして、Web Terminal 上で KUBECONFIG 環境変数を設定します:
$ export KUBECONFIG=/home/IBMid-31000086FP/.bluemix/plugins/container-service/clusters/mycluster/kube-config-mel01-mycluster.yml

 

ここまでの作業が完了すると Web Terminal から kubectl コマンドを実行できるようになり、コマンドを通じてワーカーノードの状態を確認することもできるようになります。この kubectl コマンドも特にセットアップすることなく、Web Terminal 上でそのまま実行できます:
$ kubectl get nodes

1つだけ動いているワーカーノードが、名称や状態とあわせて Web Terminal 上に表示されます:

2019041113


先程ウェブ画面で確認したものと同じ内容が表示されました。これでこの Web Terminal 上から Kubernetes クラスタを操作できることが確認できました。


では続けてこのノードにアプリケーションをデプロイしてみます。Kubernetes の公式チュートリアルで紹介されている内容と全く同じ操作を Web Terminal から行ってみます。

デプロイメントの名前(以下の例では kubernetes-bootcamp)とアプリケーションイメージの Docker Hub リポジトリ URL (同 gcr.io/google-samples/kubernetes-bootcamp:v1)、実行ポート番号(同 8080)を指定して kubectl run コマンドを実行し、アプリケーションイメージを Kubernetes クラスタにデプロイします:
$ kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080

このコマンドが実行されると、アプリケーションが実行可能なノード(今回ははじめから1つしか用意してないので、その1つ)を探し、アプリケーションの実行がスケジュールされてデプロイが実行されます。

実行後に以下のコマンドでデプロイメントの状態を確認してみます。以下のような感じで、1つのアプリケーションが実行されている状態になればデプロイは成功しています:
$ kubectl get deployments
NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1         1         1            1           16s

また、この時点で Pod の状態も確認しておきます。デプロイ時に特にレプリカ数を指定していなかったので、1つの Pod が起動され、その上でアプリケーションが起動しているはずです:
$ kubectl get pod
NAME                                   READY   STATUS    RESTARTS   AGE
kubernetes-bootcamp-598f57b95c-w2k4b   1/1     Running   0          2m7s

次の段階に進む前に、いったん作成した Pod を削除しておきます。作成時に指定した名前(kubernetes-bootcamp)を指定してデプロイメントを削除します:
$ kubectl delete deployment kubernetes-bootcamp
deployment.extensions "kubernetes-bootcamp" deleted

$ kubectl get deployments
No resources found.

$ kubectl get pod
No resources found.

↑念の為、デプロイメントと Pod が存在しなくなっていることも確認できました。次回、最終回に改めてアプリケーションをデプロイして、スケールさせたりした上で使ってみることにします。

久しぶりに IBM Cloud の Kubernetes サービスを使ってみたら、色々変わっていたので、自分の備忘録を兼ねてまとめてみました。そういえば IBM Cloud(Bluemix) 記事を書くのは久しぶりかも。。 (^^;

まず、現在 IBM Cloud では無料で1ワーカーノードの Kubernetes サービスが使えます。ここで少し注意が必要です。IBM Cloud にはライトプランと呼ばれるアカウント・プランがあり、クレジットカードすら不要な登録作業によって無料で IBM Cloud のアプリケーション・サーバーやデータベースといったサービスを一定量ですがずっと使うことができます(どこかみたいに12ヶ月無料、とかではありません)。これはこれで非常に便利なアカウントプランなのですが、今回紹介する「無料の Kubernetes サービスがライトプランで使えるわけではない」という点に注意が必要です。 詳しくは後述しますが、この無料の Kubernetes サービスは(有償の)スタンダードアカウント向けに無料で提供されているサービスプランの1つです。つまり前述のライトプランで使えるものではない、という点に注意が必要です。自分はスタンダードアカウントを持っているので、それを使って以下の確認作業を行いました。


というわけで、実際に無料の Kubernetes サービスを利用するにはスタンダードアカウントで IBM Cloud にログインする必要があります。そしてログイン後に「リソースの作成」をクリックします:
2019041101


利用するサービスをカタログから選択します。今回は「コンテナ」カテゴリから「Kubernetes Services」を選択します:
2019041102


次の画面では有料のものも含めたサービスプランの種類が一覧で確認できます。無料(free)プランではワーカーノードが1つという制限がありますが、料金はかからないことが確認できます。また今回の説明の対象ではありませんが、有料プランの場合の各ノードのスペックと料金を確認することもできます。ここではとりあえず「Create」ボタンをクリックします(ライトプランだと、この「Create」ボタンが押せないはずです):
2019041103


次の画面で Kubernetes クラスタのタイプを指定します。まずデフォルトで有料の「Standard」が選択されていると思いますが、ここを「Free」に変えて無料プランに切り替えます(Standard のままだと課金対象になります)。そしてリソースグループ、データセンターの場所を指定します(以下の例ではリソースグループは default、場所は Asia Pacific の Sydney を選択しました)。また(ワーカーノードは1つですが)クラスタの名前を指定します(以下の例では mycluster としています)。 ここまで指定して画面右上の Total が Free (無料)になっていることを確認し、「Create cluster」ボタンをクリックして Kubernetes クラスタを作成します:
2019041104


すると Kubernetes クラスタの画面に切り替わります。切り替わった直後のステータスは "Registered" となっていますが、登録作業が進み準備が完了すると "Normal" に切り替わるので、それまでしばらく待つ必要があります。またこの無料 Kubernetes クラスタは1ヶ月間限定で利用できます。1ヶ月後に expire される旨が表示されている点も確認してください:
2019041105


ステータスが "Normal" に変わるとこのようになります。これで Kubernetes クラスタが稼働している状態になりました:
2019041107


"Worker Nodes" タブに切り替えた画面です。このプランではワーカーノードは1つだけしか使えませんが、その1つのワーカーノードが正しく動いていることを確認します:
2019041108


とりあえず、スタンダードアカウントを使って無料の Kubernetes サービスを有効にして、1ワーカーノードのクラスタが利用できるようになりました。



 

「ウェブ魚拓」というサービスをご存知でしょうか?ネット上のウェブサイト(URL)を独自にキャッシュして保存するサービスのことです。ネット上のウェブサイトがなくなってしまったり、内容が変わったりしても、その保存したタイミングでのウェブサイトを後からでも参照できるように残す、というサービスです。

このウェブ魚拓もどきのサービスを Node.js 向けに作って、ソースコードを公開しました:
https://github.com/dotnsf/urlrec

2019020801


まず、この公開したサービスではあらゆる全てのサイトでキャッシュを残せるわけではありません(いわゆる「対策済みサイト」に対しては、この機能は無効です)。残せるサイトの場合は独自フォーマット(本当は MHTML にしたかったんですが、色々難しそうだったので、画像だけインライン展開するフォーマットで HTML と画像を記録できるようにしました)でキャッシュを記録します。つまり取得時点でのテキスト内容と画像をキャッシュして記録します。

また記録先として IBM CloudIBM Cloudant サービスが必要です。必要に応じて IBM Cloud のアカウントを作成し、IBM Cloudant サービスインスタンスを作成しておいてください:
2019020802


ソースコードを入手する前に、IBM Cloudant インスタンスを利用するための接続情報を確認しておきます。作成したサービスインスタンスの「サービス資格情報」メニューから「資格情報の表示」を選択(見当たらない場合は1つ新規に作成してから選択)すると JSON フォーマットの接続情報が表示されます。この中の username と password の値を後で使うことになるので、このページを開いたままにしておくなどしてコピー&ペーストできるようにしておきます:
2019020803


では改めてソースコードを入手します。https://github.com/dotnsf/urlrec から git clone するか、下図のように zip をダウンロード&展開してソースコードを手元にコピーします:
2019020804


ソースコードが入手できたら、settings.js ファイルをテキストエディタで開きます。そして exports.db_username の値を先程確認した IBM Cloudant の接続情報の username の値に、exports.db_password の値を同じく password の値に、それぞれ(コピー&ペースト等で)書き直して保存します:
exports.db_username = '(username の値)';
exports.db_password = '(password の値)';
exports.db_name = 'urlrec';
: :

Node.js が導入されていればローカル環境で動かすことも可能です。その場合は以下のコマンドを実行します:
$ npm install  (依存ライブラリを導入)

$ node app  (実行)

server stating on XXXX ...

成功すると上記のように "server starting on XXXX ..." と表示されます。この XXXX は数字になっているはずで、ウェブ魚拓サービスはこのポート番号で待ち受けている、ということを示しています。


では実際に使ってみましょう。先程確認した XXXX を使って、ウェブブラウザから http://(サーバー名 または IP アドレス):XXXX/ にアクセスします。以下のような画面が表示されれば成功です:
2019020805


画面上部の "URL" にキャッシュしたいページの URL を入力して "CHECK" ボタンを押すとプレビューが表示されます(このプレビューが表示されないページは非対応だと思ってください)。下の例では試しに自分のブログの1ページを指定してみました:
2019020801


そしてプレビュー画面で(必要に応じてテキストコメントを入力した上で) "Record" をクリックするとキャッシュがシステムに保存され、先程の画面内に一覧表示されます:
2019020802


この画面で一覧内の一番左の列(赤枠部分)をクリックすると、別ウィンドウが開いてキャッシュされた内容を確認することができる、というものです(元の URL の記事が削除されていても見れるようになります):
2019020803


UI的にもまだまだシンプルすぎる所があったり、元のページのスタイルの再現性など、まだまだ改良の余地はあると思っていますが、基本機能は実装できていると思ってます。MIT でソースコードを公開しているので、役に立つ場があればご自由に使っていただきたいです。

そろそろプロ野球のシーズン開幕前順位予想とかが始まるので、それらを片っ端から記録しておこうかなあ、と邪な考えを持っていたりします。 σ(^^;


個人的な野望としてはこれを元に更に改良してブロックチェーンと組み合わせて真偽証明付きにして・・・って感じかなあ。

2019 年最初のブログ投稿に、普段感じる事が多いけどあまり触れていなかった点について書いてみようと思います。ちょっとだけマジメな話です。


拙作「マンホールマップ」は 2010 年からサービスの開発を始めて、ほぼ同時期からサービスを開始しています。色んな人のアイデアを参考にさせていただくことはありますが、基本的には私一人で開発を行い、管理を含めた運営を行っています。もう8年以上続けていることになります。今は当時と比べてもクラウドをはじめとする時代背景が大きく変化し、個人でウェブサービスを開発・管理・運営する環境が整っていると感じていますが、そういった業務で開発・運営するのは異なる部分について、一度まとめておこうと思いました。


【背景】
まずはいい意味での違いを。ここ数年のクラウド環境の充実、そして低価格化によって、個人がウェブサービスを運営しやすくなったと感じています。

後述もしますが、ウェブサービスを「作る」ことに関しては開発環境さえ整えればいい話ですが、それを公開して運営するにはドメインの取得に加え、インターネット上に公開された24時間稼働が可能なサーバー機を用意する必要があります。企業で運営する場合、専用サーバーや専用回線を調達する方法もありましたが、個人には(主にコスト面で)敷居の高いものでした。また以前から「ホスティングサービス」と呼ばれるサービスでインターネット上のサーバーを借りることはできましたが、技術的な制約も大きく、開発上のハードルが上がってしまうものでした。

この点において、世の中でクラウドが広まり、特に PaaS 環境が広まってきたことで、サーバー環境の準備や構築だけでなく、(標準で用意されているものを使うことで)ドメインや証明書の取得まで不要になる時代になったことを実感します。こうなると個人でもサービス/アプリケーションを開発できれば、その運用を開始するまでのハードルはぐんと低くなっていると感じます。


以上のように個人がウェブサービスの運営を開始するまでのハードルは低くなりましたが、一方で実際に運営する段になると業務で行う場合とは異なる点を意識する必要があることも実感するようになりました。そんな背景における違いを、実際に運営する中で気付いた範囲で言及してみようと思います。



【個人で開発・運営するのは業務で行う場合と何が違うのか?】
一言でいえば個人運営だと「全部自分でやる」点が違います。何を作るのか、どこまで作るのか、いつまでに作るのか、どんな画面にするのか、どんな実装で実現するのか、プログラミング言語は、データベースは、OS は、どこで動かすのか、ドメイン名/ホスト名は、コストはいくらまで出せるのか、問い合わせ対応は、フィードバック対応は、・・・ 決めるのも実行するのも自分一人です。

一方、業務で行う場合、もちろんその企業の規模とかにもよると思いますが、多くのケースで分業制が考えられます。開発部分ひとつ取っても、デザインと実装は担当分野が分かれるケースが多いですし、インフラの構築とアプリの開発は別チームというケースも少なくありません。が、個人だと分ける相手がいません。「UIデザインは苦手」とか言ってられないのです。

また開発後の運用やサポートも自分で行います。業務だと電話サポート窓口があったりしますが、普段は本業を持つ個人開発者がサポート業務に従事することはできません。サーバーが止まっていても気づける人がいない※のです。 となると「なるべくサポートが不要になるような設計」をはじめから意識して作る必要があります。マンホールマップの例だと不適切な画像を投稿する人がいたらどうするか?という問題がありました。ここは Twitter アカウントとの連携で不適切な画像を投稿しにくくする、という形にしました。要は投稿時には Twitter アカウントによるログインが必要で、不適切な画像を投稿すると Twitter 側にもバレる、というリスクを利用者に課したのです。そうすることで、そういった愉快犯的に不適切画像を投稿する人を少しでも減らそうという試みでした。幸いにしてサービス開始から悪質な投稿をする人はほとんど表れていません。ある程度の効果はあったのかもしれませんが、こういったサービス設計段階における考慮も必要になるのでした。

※ちなみに上述の「サーバーが止まっている場合も気づける人がいない」問題は Google Search Console のサーバーエラーをメールで通知する機能で解決できます。自分で解決する必要はないのですが、こういった世の中のツールを知っていたり、調べたりする能力も必要になってきます。


【ドメインの問題】
自分でサービスを作るだけならずっと以前から(自分の手元のPCに開発環境を用意すれば)できたことです。以前はいざ公開・運営するとなった場合に「どこで」公開するか、という問題がありました。何というホスト名(ドメイン名)で公開するか、という問題です。 試験的・限定的に公開するだけなら IP アドレスでも(特殊なポート番号でも)いいと思うのですが、公開するとなるとそうも言えません。

加えて SSL 証明書の問題もあります。最近は外部 API と連携する際の条件として https 通信が可能なことが求められることも珍しくなくなりました。ドメインを取得した上で SSL 証明書を取得し、https 通信を有効にすることが必須となることもあります。

もちろんオレオレ証明書でも NG ではないし、最近は SSL 証明書も安く取得できるようになってはいますが、ドメインの取得は無料というわけにはいきません。つまりいくばくかの運用コストが無視できなくなってしまいます(コストについて詳しくは後述します)。またその手続や設定を運用開始までに済ませて置かなければならないのだとすると(上述の「一人でやらなければならない」という条件も考慮して)運用開始までの負担が大きくなってしまうのでした。

ただ、この辺りも昨今のクラウド環境の、特に PaaS と呼ばれるサービスを利用することで、特に存在を意識しなくても使える DNS やドメイン名があったり、はじめから SSL が利用可能になっていたりするものもあります。こういう環境が広まっていくことは個人開発者としても大歓迎です。


【コストの問題】
クラウドはウェブサービスの運用を開始するまでの技術的なハードルを大幅に下げてくれることを上述しました。では難しいところはクラウドにおまかせする形で、クラウドベンダーの環境で公開することに問題はないのでしょうか?

現実問題としては「コスト」が問題となるケースがあると思っています。アプリケーションサーバー1台とデータベースサーバー1台での運用であれば、最悪1台の IaaS の中に同居させてしまう形にして、理論上はこの1台ぶん最低限のサーバーの月額コストだけで運用することができます(月 500 円程度から可能です)。

ただ実際には「最低限のサーバーの月額コスト」ではまかなえないケースが多くなると思っています。その最低限のサーバー1台に搭載されたメモリ量で動くのか? IaaS の中にデータベースを同居させたディスクの容量は足りるのか? 足りたとしてもデータのバックアップをどう考えるか? 上述のドメインに関わるコストも無視できません。  ・・いずれもクラウドサービスにコストをかけることで解決できることが多いのですが、そのコストは経費ではなく個人負担なのです。クラウドのデータベースって、冗長性とかバックアップとか考えなくていいのは確かに便利ですが、(安価な仮想サーバーほど)安くはないですよね。。それを個人で、しかも毎月負担できるのか、、という問題です。とはいえ万が一バックアップがないサーバーが死んでしまったら・・・と考えると、公開する以上は考慮しないといけない問題なわけで、、、


これも私の話で恐縮ですが、自作ウェブサービスのほとんどはクラウドで公開していますが、マンホールマップは 2019 年1月時点で自宅サーバー運用しています。一番に理由はコストで、上述の要素を考慮してクラウドサーバーを用意すると毎月コストが結構な額になってしまい、それなら自宅に安いサーバー(というかPC)を買ってなんとかしたほうが現実的、という判断に至ったのでした。


【で、結局・・・】
まとめると、こんな感じでしょうか:

- 昨今のクラウド環境の充実によって、開発したウェブサービスを公開して運用するのは安価かつ容易になった。
- 非機能要件を無視できる間はそれでもよいが、ある程度データが溜まってくると万が一の際のバックアップなどを無視できなくなる。
- その辺りまで考慮しはじめると「クラウドが安い」と言い切れなくなってくる。がんばって自宅ネットワーク内のサーバーを公開したほうが安上がりになるケースも。
- 自分一人で管理する前提でサービスレベルを考慮/設計する必要がある。
- 個人ウェブサービスは開発/運営するのは(一通り全てをある程度のレベルでこなさないといけない、という意味で)すごくいい勉強になる。



↑実は最後の一文を言いたくてこの長いブログエントリを書きました。業務経験としては個人開発や個人運用は評価しにくいのかもしれませんが、これを一人でこなせることも、一人でもこなせるような設計をしていることも、本当はもっと高く評価されてもいいんじゃないかなあ、、、と思っているのでした。

クラウド環境が広まったことで個人ウェブサービスを運用するハードルは確実に下がっています。この環境を活用して、色々な人がウェブサービス運営に興味を持ってもらえると嬉しいし、それは技術者としての(業務にも関わる)スキルアップに確実につながると思っています。

このページのトップヘ