おいしいフルOSSクラウドの食べ方

前回までの連載では、NTTデータの「フルOSSクラウド構築ソリューション」を中心に、OSSによるプライベート・クラウドの設計・構築・運用について説明してきました。

最終回となる第4回では、実際にNTTデータ社内で運用しているプライベート・クラウドの事例をもとに、クラウドの構築・運用のポイントや、過程で得られた教訓について解説します。また、最近になって激しい動きを見せているクラウド構築用OSSの最新動向も合わせて紹介し、連載を締めくくります。

4.1. 運用事例

4.1.1. 社内クラウドの概要

筆者らは、NTTデータ社内、特にR&D部門向けのIaaSサービスを運用しています。このIaaSサービスは、NTTデータのプライベート・クラウド構築用製品サービス群「フルOSSクラウド構築ソリューション」のテストベッドとして位置づけられています。サービスの特徴を、以下に列挙します。

総じて、いつでも気軽にサーバー環境が手に入ることから、小規模なサービスの提供や、機能検証に使われる事例が多いようです。逆に、マルチテナントかつ仮想マシン環境という特性から、ほかの利用者への性能面での影響を完全には排除しきれないため、シビアな性能が要求される用途には不向きといえます。

提供形態: セルフサービス型

サービスの特徴としてまず第1に挙げられるのが、利用者が自らの手で仮想マシンを起動したり停止したりできるセルフサービス型であるという点です。利用者から見た場合、素早く柔軟に資源を利用できるというメリットがあります。同時に、クラウド運用者から見た場合、利用者が仮想マシンを正常に利用できている限り、特別な運用作業が発生しないため、運用負荷を低減できるというメリットがあります。

提供規模:

仮想コア数換算で150～200程度のコアを収容できる規模で、1つのプライベート・クラウドのサービスを提供しています。登録ユーザー数は100名強、アクティブな利用者数はおよそ30～40名で、定常的には60～80台の仮想マシンが動作していることが多いようです^*1。ハードウエア構成としては、ブレード・サーバーを利用し、ストレージからクラウド内スイッチを含めて1ラックに収まるコンパクトな構成をとっています。

• [*1] クラウド運用者が特にアクションをとらずとも、アクティブ・ユーザー数や仮想マシン数にある程度の幅があるのが、セルフサービス型クラウドの特徴です。

用途:

セルフサービス型らしく、用途はかなり多岐にわたります。中でも、以下のような用途が代表格として挙げられます。

社内向け広報サーバーのプラットフォームとして

チームの広報窓口となるWebページを、クラウドを利用して公開する事例です。クラウドがあるおかげで、数名ほどの小規模なチームでも低コストでサーバーを利用できるため、サーバーを設置することに対するハードルが下がっているようです。

プロジェクト管理や情報共有用サーバーのプラットフォームとして

Trac/Subversionの環境をクラウド上に構築し利用している例が多く見られます。変わり種としては、メンバーのコミュニケーションの促進を目的としてTwitterクローン^*2を動作させる事例もあります。

• [*2] 筆者らが所属する部署では、status.net（http://status.net/）というTwitterクローンが人気のようです。

アプリケーションの動作検証プラットフォームとして

いろいろなOS環境が手に入るため、手軽にアプリケーションの動作を検証する目的で使用する事例が多いようです。

4.1.2. 社内クラウドの運用のポイント

4.1.2.1. 運用範囲の明確化

クラウド上で動作している仮想マシンに関しては、クラウド運用者の責任の範囲外としています。なぜなら、セルフサービス型では、クラウド運用者はクラウド上の仮想マシンの詳細を把握しておらず、管理者権限も所持していないことから、監視・バックアップなどの運用作業を実施することが難しいからです。クラウド運用者は、クラウド基盤のみを運用します。これにより、運用コストを低く抑えることができます。

4.1.2.2. 運用作業

クラウドといっても、特有の運用方法があるわけではありません。通常のシステム運用と同等の作業が必要です。

（1）クラウド・インフラの監視

クラウド運用者は、クラウド上で動作するすべての仮想マシンについて、起動・利用できるようにする責任があります。クラウド基盤とそれを支えるハードウエアの異常を早期に検知・解決することは、運用者にとって最も重要な作業と言っても過言ではありません。

Hinemosをはじめとした運用監視ソフトを導入して障害を検知するだけでなく、障害発生時の対応フローを作成して、障害を早期に解決できる体制を整えることが重要です。本システムでは、利用者向けの連絡文書のテンプレートや、障害解析用ツール、ハードウエア保守の連絡先など、障害の早期解決に役立つものは可能な限り事前に準備しています。

（2）バックアップ

セルフサービス型クラウドでは、バックアップ対象のデータについて、十分に検討する必要があります。まず、クラウド上で動作中の仮想マシンをバックアップ対象とするかどうかの検討が必要です。本システムでは、動作中の仮想マシンが持つデータのバックアップは、利用者側の責任としてバックアップ対象から除外しています。ただし、利用者から依頼のあったデータ（保存した仮想マシン・イメージや永続化ストレージの内容など）は、運用者側でバックアップ対象としています。

もちろん、クラウド・インフラ側の設定情報やユーザーの管理情報、ログなどは最初からバックアップ対象としています。

（3）アカウント管理

新規にアカウントを作成する際には、予定しているリソースの使用量と使用期間を申告してもらうことにしました。クラウド・リソースの残量と、既存の利用者の利用予定期間を考慮し、利用者の受け入れが可能かどうかを判断します。

セルフサービス型において、アカウントの作成は、運用者が利用者とコンタクトをとる数少ない機会です。本システムでも、利用規約の提示や利用者からの情報収集（連絡先など）を、このタイミングで実施することで、運用を効率化しています。

4.1.3. 運用中に得られた教訓

社内クラウドの運用は、手探りで始めたこともあり、運用の過程で多くの課題が見つかりました。そのなかでも、特に"クラウドならでは"という課題と、それから導きだされる教訓について、以下に2点紹介します。

（1）キャパシティ・プランニング

利用者のリソースに対するコスト意識が少ない場合、利用しなくなったリソースを解放するモチベーションが低くなりがちです。結果として、リソースを使用していることを忘れてしまう場合や、リソースの返却が面倒などの理由で、無駄にリソースを占有してしまう場合がよくあります。

逆に、クラウドに用意したリソースが使われていないことも無駄です。想定される利用者数や規模をあらかじめ吟味しておくことが必要です。また、みなし課金や定期的な棚卸しといった、リソースを有効活用する動機やきっかけを利用者側に与えることが大切です。

（2）費用対効果の可視化

導入後の利用実績や導入効果の把握／報告は、重要なタスクです。

クラウド基盤の利用状況（リソースの払い出し状況や各種負荷情報など）を収集し、実績を定量的に把握できる仕組みを必ず導入しましょう。また、セルフサービス型の場合、払い出されたリソースの利用状況に関して、利用者に問い合わせる必要があります。アンケートなど、利用者から情報を集める方法を定めて継続的に実施することにより、費用対効果を可視化しておくことが大切です。

4.1.4. 今後の取り組み

これまでの運用を通じて、社内でプライベート・クラウドを運用する際の課題が明らかになってきました。今後は、社内のテストベッドという位置づけでの運用を継続しながら、利用実績に合わせたサービス・メニューや、その提供方法などの改善を行う予定です。