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

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

タグ:autoscale

とうとう IBM Bluemix 上のランタイムとして Domino サーバーが登場しました。詳しくはこちらを参照ください:
Domino on Bluemix


IBM Notes/Domino は IBM が開発/販売しているコラボレーションプラットフォームです。多くの企業でエンドユーザーコンピューティングやグループウェアの基盤として使われ、多くのビジネスパートナー様による関連製品/サービスもリリースされています:
2015081202



今回リリースされた XPages(Domino) ランタイムは、パブリッククラウドである Bluemix 上で、サーバー機能である Domino が稼働する環境を提供するものです。そこだけを見ると嬉しいニュースなのですが、ではこの Domino は Bluemix とどこまで親和性があるのでしょうか? たとえば Bluemix では Java や PHP などのアプリサーバーと、DB2 や MySQL などのデータベースサーバーは分離されています。そのため、アプリサーバー部分だけを負荷に合わせて手動でスケールアウトさせることもできますし、そのスケールイン/アウトを自動化させる、いわゆる「オートスケール」の設定を組み込むことも可能です。

一方、Domino サーバーは「オールインワン」型でした。アプリサーバーもデータストアもその中で動くアプリケーションも、更にはユーザーディレクトリや HTTP, タスクスケジューラといったサブタスクも全て一元化されたサーバーを使っていました。考え方としては1つのサーバーが全ての機能を持ち、負荷分散でサーバーを複数台対応させる場合にはデータも複製して対応する、というアプローチでした。

ある意味で相反する考え方を持つ Bluemix のランタイムと Domino ですが、ではこの Domino ランタイムが Bluemix 上で動く場合に、Bluemix のスケーリングの考えは適用できるのかどうか?という疑問が生じます。

具体的には Bluemix 上の Domino は Java や PHP アプリサーバーのように簡単に複数台対応できるのか?同様にオートスケール設定ができるのか?その場合のデータの整合性はどのようにして保つのか/保たれるのか? といった疑問です。


結論を先に言うと、Bluemix 上の Domino は(条件付きで)スケール対応します。Java や PHP と同様のインターフェースやオートスケールサービスを使って、動的に Domino サーバーを複数台対応させることができます。その際に Domino 固有のデータ複製設定などは必要ありません。

でも「なぜそんなことが可能なのか?」という疑問が生じるはずです。それについて正確に表現すると「Bluemix 上で .nsf ファイルを XPages 設計要素と、ビュー/フォーム/文書の要素に分けてプッシュする形でデータベースアプリケーションをデプロイすればスケーリングに対応できる、ということになります。つまり .nsf ファイルを設計とデータとに分離します。そして前者をランタイムで、後者をサービスで運用する形を取り、更にランタイムから分離先のデータサービスを正しく参照して文書データをデータサービス内だけに保存するような設計にするという条件を付けることでスケーリングが可能になる、ということです(ランタイム側にもサービス側にも .nsf ファイルが必要です):
2015081201


これを実現するには XPages の仕組みが必要になり、加えて既存 XPages アプリの設計を少し改良する必要もあります。具体的には、例えば XPages の設計要素でデータベースファイルを指定する箇所を以下のように指定します:
<xp:dominoView databaseName="myapp_data.nsf"> 
  ↓
<xp:dominoView databaseName="#{javascript:bluemixContext.isRunningOnBluemix()? bluemixContext.getDataService().findDatabaseName() : 'myapp_data.nsf'}"> 


この処理内容は XPages 内で JavaScript を使って「Bluemix 環境であればバインドされているデータベースを使う、Bluemix 環境でなければ myapp_data.nsf を使う」という処理を記述しています。つまり Bluemix 環境上で動いている時とそうでない時に分けてデータベースファイルを指定しています。Bluemix 向けに拡張された Domino Designer ではこのような記述も可能になります。このような仕組みによって Bluemix 上でスケールできるよう対応させる必要があるとも言えます。それが "(Domino on Bluemix ではなく)XPages on Bluemix" という名称にも現れているのだと思います。


というわけで、エントリ冒頭の疑問に対する答はこちらです: 
IBM Domino はスケールイン/アウトできます。Bluemix と XPages があればね♪


なお、Bluemix 上の XPages 関連ランタイムやサービスは2015年8月12日現在ではまだ「試験提供」のステータスです。上記内容は試験提供内容を元に記述しています。正式提供に向けて今後仕様変更があるかもしれないことはご了承ください。


IBM Bluemix でアプリケーションサーバーを作った場合、そのサーバーインスタンスの数やメモリ量については管理コンソール画面から(自分が持っているリソースの上限まで)動的に変更できます:
2015032615


サーバーのワークロードがある程度安定しているのであれば、これらの数値を手動で設定すればいいのですが、実際には変化するワークロードに対応するため、何らかの運用ルールを決めた上で自動的にスケールイン/アウトするように設定できると便利です。

IBM Bluemix 環境の場合、このオートスケール機能もサービスの1つとして提供されています。このオートスケールサービス自体は無料でお使いいただけます。


「無料」という意味では1点注意していただきたいのですが、IBM Bluemix はサインアップ後の30日間は無料、有料アカウント移行後もこのオートスケールサービス自体は無料でお使いいただけます。有料アカウント移行後の無料枠があり、その範囲内でご利用いただくぶんには料金は発生しません。 ただし、有料アカウント移行後にこのオートスケールサービス機能でサーバーインスタンスがスケールアウトした結果、いつの間にか無料枠を超えた状態で運用されてしまっている、という可能性がありえます。オートスケールを利用する場合の設定内容と利用料金についてはご注意ください。


では、Bluemix でのオートスケールサービスの使い方について紹介します。まずはオートスケールの対象となるアプリケーションランタイムを用意します。ここでは IBM Bluemix 上に WordPress 環境を構築して、この環境をオートスケールさせてみます(WordPress 環境である必要はありません。何か Bluemix 上で動くランタイム環境があれば、それをお使いいただいても構いません)。Bluemix 上に WordPress 環境を構築する場合の手順は以下を参照ください:
IBM Bluemix 上で WordPress 環境を構築する (少し古い記事)
IBM Bluemix で無料の WordPress 環境を構築する (比較的新しい記事、こちらがオススメ)

オートスケールの設定をするにあたり、まずは CPU やメモリの利用状況を確認します。作成した WordPress ランタイムアプリケーション(下図では dotnsf-wp)を Bluemix ダッシュボードから開き、そのプログラミング言語環境が書かれた部分(下図では PHP)をクリックします:
2015032601


このランタイムアプリケーションの現在の状態が表示されます。下図ではメモリ 128MB の1サーバーインスタンスが稼働していて、CPU 利用率は 0.1%、メモリは 128MB のうち 68.4MB が利用中、そしてディスクは 1GB のうちの 234.8MB を使っている、ということがわかります:
2015032602


この状態を元にオートスケールの条件を決めます。今はテスト的な目的もあるので、わざとスケールアウトを発生させたいため、
  メモリ利用率が 50% を超えたらスケールアウト
  メモリ利用率が 30% を下回ったらスケールイン

という(このままでもスケールアウトが発生するような)条件で運用してみます。この条件は CPU かメモリに対して設定することができますので、実際の環境を確認した上で、簡単に発生させられそうな条件を決めてください。


ではこのランタイムにオートスケールサービスを追加します。ダッシュボードに戻ってこのランタイムを選択した上で、「サービスまたは API の追加」をクリックします:
2015032603


追加できるサービスの一覧が表示されます。DevOps カテゴリーの "Auto-Scaling" サービスを選択してクリックします:
2015032604



Auto-Scaling サービスの説明と利用条件が表示され、無料サービスであることが分かります。右上のアプリ選択欄では、このサービスを追加したいランタイム(この例では dotnsf-wp)が選択されていることを確認して「作成」ボタンをクリックします:
2015032605


サービスを1つ追加したので、ランタイムを再ステージングするか聞かれます。ここで「再ステージ」をクリックしてランタイムサーバーを再ステージングします:
2015032606


しばらく待つと、先ほどのランタイムアプリケーションに Auto-Scaling サービスが追加されていることが確認できるようになります。次はオートスケールの条件を設定したいので、この Auto-Scaling サービスのアイコンをクリックします:
2015032607


オートスケールサービスのパネルが開きます。最初はまだ何のルール(ポリシー)も定義していないので作成する必要があります。「ポリシー構成」タブ内の「自動スケーリングポリシーの作成」ボタンをクリックします:
2015032608


最初のポリシールールを編集する画面になります。名称などは適当に付けるとして、設定すべきは具体的なルールの部分です。まずスケールイン時の最小インスタンス数はデフォルトの1のままとして、スケールアウト時の最大インスタンスは念のため4にしてみます。現在は1インスタンスのメモリが128MBなので、4インスタンスまで稼働させても無料枠内、という安心設定です(笑)。 またメトリックタイプを「メモリー」に、スケールアウトの条件を(メモリ使用率)50% 超えと設定します。これで何もしなくても今のままでスケールアウトしてくれます。 更に細かい条件を設定するため「拡張構成」をクリックします:
2015032609


拡張構成では、どれだけの期間測定してスケールイン/アウトを判断するか?を指定できます。デフォルトでは600秒(10分)になっていますが、今回はなるべくすぐに確認したいので最小値の120秒(2分)に設定し、最後に「保存」ボタンをクリックします:
2015032610


確認メッセージが表示されればポリシーの定義ができました:
2015032611


そのままダッシュボードの言語タブ(下図では "PHP")に移ってしばらく様子を見ていると、スケールアウトの様子が見えてくるはずです。これは1インスタンス増えて2インスタンスになった様子:
2015032612


条件を厳し目に設定したので(苦笑)、2分おきにインスタンスがどんどん増えていきます。設定最大値である4インスタンスまで順調に(?)増えていきました:
2015032613


この状態でダッシュボードの "Auto-Scaling" サービスを選択して、スケーリング履歴タブを開くと、この時のスケールアウトの様子が記録されており、一覧で参照することもできます:
2015032614


IBM Bluemix はアプリケーションサーバーであるランタイムと、データベースなど各種サービスを組み合わせて環境を構築するのが特徴ですが、オートスケーリングに関してもサービスの1つとして提供されており、簡単に使えることも分かっていただけるのではないかと思っています。メモリだけでなく CPU 状態でも設定できるので、用途・目的に合わせて使ってみてください。


このページのトップヘ