第3章 スケーリング

クラウドのスケーラビリティを決定することと、それをどう改善するのかは、多くの変数のバランスをとる問題です。万人のスケーラビリティ目標に適した解決策は存在しませんが、いくつかの指標を観察しておくと役に立つでしょう。

ほとんどの場合の出発点は、クラウドのコア数です。なんらかの比率を掛けることにより、実行される仮想マシン(VM)の数の期待値についての情報を得られます。 ((オーバーコミット率 × cores) / インスタンスごとの仮想コア数), 必要なストレージ容量は (フレーバーごとのディスクサイズ × インスタンス数). あなたのクラウドにどの程度の追加機材が必要なのか、これらの比率で判断することができます。

OpenStack のデフォルトフレーバー:

以下の構築例では、 (200 / 2) × 16 = 1600 VM インスタンスをサポートし、 /var/lib/nova/instances 以下に80TBのストレージ領域が必要なものとします。

しかし、APIサービスやデータベースサーバー、MQサーバーがおそらく遭遇する負荷を見積もるためには、コア数以外の検討も行う必要があります。クラウドの利用パターンも考慮しなければなりません。

特定の例としては、マネージドWebホスティングプラットフォームをサポートするクラウドと、コードコミットごとに仮想マシンを１つ作成するような開発プロジェクト用の結合テストを動かしているクラウドを比較してみましょう。前者では、VMを作成する重い処理は数か月に一度しか発生しないのに対して、後者はクラウドコントローラーに定常的に重い処理を発生させます。一般論として、VMの平均寿命が長いということは、クラウドコントローラーの負荷が軽いことを意味するため、平均的なVMの寿命を検討しなければなりません。

仮想マシンの起動、停止以外では、ユーザーアクセス、特に nova-api と関連データベースへのアクセスの影響を検討しなければなりません。インスタンス一覧を取得する処理は膨大な量の情報を収集しますし、ユーザーがこの処理を頻繁に行うと、ユーザー数が多いクラウドではこの負荷が著しく上昇します。この負荷は、ユーザーが知らずに発生します。つまり、ブラウザのOpenStack ダッシュボードのインスタンスタブを開いたままにすると、30秒ごとに仮想マシンの一覧が更新されます。

これらの要素を検討した後、クラウドコントローラーにどのくらいのコア数が必要なのか決定することができます。上記の注意事項において、典型的には、ラック1本分のコンピュートノードに対して8コア、メモリ8GBのサーバーで充分です。

ユーザーの仮想マシンの性能のために、ハードウェアのキーになるスペックも考慮に入れなければなりません。予算と性能への需要を検討するのです。例としては、ストレージ性能(スピンドル / コア)、メモリ(メモリ量 / コア)、ネットワーク帯域(Gbps / コア)、そして全般的なCPU性能 (CPU / コア)です。

クラウドをどうスケールさせるのか決定するために観察すべき指標については、14章ロギングと監視 を参照してください。

クラウドの水平的な拡張は、ノード追加によって容易に実行することができます。コンピュートノードの追加は簡単です。新規のコンピュートノードは既存のシステムから簡単に認識されます。しかし、クラスタを高可用なものにするためには、設計の際にいくつかの重要なポイントを検討しなければなりません。

クラウドコントローラーは、いくつかの異なるサービスを実行することを思い出してください。拡張のための新しいサーバーには、  nova-scheduler や nova-console のようなメッセージキューを用いて内部でのみ通信するサービスをインストールすることができます。しかし、他の不可欠な部分についてはもっと注意が必要です。

ダッシュボードやnova-api 、Object Storage proxy のようなユーザー向けのサービスは負荷分散するべきです。任意の標準的なHTTP負荷分散方法 (DNSラウンドロビン、ハードウェアロードバランサ、Pound や HAProxy のようなソフトウェア) を使ってください。ダッシュボードに関する注意事項の一つは、VNC proxy が使う WebSocket プロトコルです。これは、L7ロードバランサで苦労することになるかもしれません。以下のリンクも参照してください。 Horizon session storage (http://docs.openstack.org/developer/horizon/topics/deployment.html#session-storage).

nova-api や glance-api のようなサービスは、設定ファイルのフラグを変更することによって複数プロセスで処理させるように設定できます。これによって一台のサーバの複数のコアの間で処理を共有できるようになります。

MySQLの負荷分散にはいくつかのオプションがありますし、RabbitMQ はクラスタリング機能を持っています。これらや他の多くのサービスの設定方法に関する情報は運用の章で見つけることができます。

クラウドを分離するためには、次に挙げる OpenStack の方法を使います。 セル, リージョン, ゾーン そしてホストアグリゲート です。これらは以下の表で述べるように、それぞれ異なる機能を提供します。

この選択肢の表は２つに分けると一番良く理解することができます。１つは、別々の Nova デプロイメントが動作します (セルとリージョン)。もう一つは、単一の Nova デプロイメントを分割するだけです。(アベイラビリティゾーンとホストアグリゲート).

 アベイラビリティゾーンとホストアグリゲート

一つの nova デプロイメントを分割するのに、アベイラビリティゾーン、ホストアグリゲート、もしくはその両方を使うことができます。

アベイラビリティゾーンは、ホストアグリゲートを利用して実装されており、ホストアグリゲートと同様の方法で設定します。

しかし、アベイラビリティゾーンとホストアグリゲートは別の理由で使用します。

• アベイラビリティゾーン: OpenStack Compute ホストを論理グループにまとめて、（独立した電源系統やネットワーク装置を使うことなどで）他のアベイラビリティゾーンとのある種の物理的な分離や冗長性を実現できます。

  サーバー毎に、指定したサーバーが所属するアベイラビリティゾーンを定義します。一般に、アベイラビリティゾーンは共通の性質を持つサーバーの集合を識別するために使われます。例えば、データセンターの一部のラック群がある一つの独立した電源系統につながっている場合には、これらのラック群に設定されたサーバーを専用のアベイラビリティゾーンに入れることができます。また、アベイラビリティゾーンは異なるクラスのハードウェアを分割するのにも使うことができます。

  ユーザーはリソースを作成する際に、インスタンスを作成するアベイラビリティゾーンを指定することができます。これによって、クラウドの利用者は、自分のアプリケーションのリソースが異なるマシンに分散して配置されることを保証でき、ハードウェア故障が発生した場合でも高可用性を達成することができます。

• ホストアグリゲート: 負荷分散やインスタンスの分散配置のために、 OpenStack Compute のデプロイメントを論理グループに分割することができるようになります。ホストアグリゲートを使って一つのアベイラビリティゾーンをさらに分割することもできます。例えば、ホストアグリゲートを使うことで、一つのアベイラビリティゾーンを、ストレージやネットワークなどの共通のリソースを共有するホストのグループや、トラステッドコンピューティングハードウェアのような特別な性質を備えたホストのグループ、に分割することができるでしょう。

  ホストアグリゲートのよくある使い方は nova-scheduler で利用する情報を提供することです。例えば、ホストアグリゲートを使って、特定のフレーバーやイメージを共有するホストの集合を作成することができます。

注記

以前はすべてのサービスにアベイラビリティゾーンがありました。現在では nova-compute サービスだけが自分のアベイラビリティゾーンを持っています。 nova-scheduler, nova-network, nova-conductor といったサービスは常にすべてのアベイラビリティゾーンにまたがる形になります。 次の操作のいずれかを実行すると、これらのサービスは内部アベイラビリティゾーン (CONF.internal_service_availability_zone) 内に表示されます。 nova host-list (os-hosts) euca-describe-availability-zones verbose nova-manage service list 内部アベイラビリティゾーンは (非冗長モードの) euca-describe-availability_zones では表示されません。 CONF.node_availability_zone は CONF.default_availability_zone に名前が変更されました。このオプションは nova-api サービスと nova-scheduler サービスでのみ使用されます。 CONF.node_availability_zone は今も機能しますが、非推奨扱いです。

OpenStack をインストールしてデプロイするのに有用な情報源が既にいくらか存在していますが、自分のデプロイメントで事前に計画を立てておくことは非常に重要です。このガイドでは、OpenStack用にラックを少なくとも１本用意しておくことを想定してしますが、いつ、何をスケールさせるのかについてのアドバイスも行っています。