2015.05.15

高品質なクラウドを支えるインフラ設計

KDDIクラウドプラットフォームサービス(以下、KCPS)のインフラ担当の加藤真人です。今回は、2月1日にリリースされたKCPS(Ver2.0)の隠されたインフラ設計を紹介させて頂きます。KCPSはKDDIのクラウドにおけるIaaSとしてこれまで沢山のお客様にご利用頂いていますが、KCPS(Ver1.0)はお蔭様で満員御礼となり、更なる拡張がおこなわれたのがKCPS(Ver2.0)となります。新たな機能も追加され、より一層「Quality Cloud」を追及したサービスとなっており、Quality Cloudを支えるインフラもさらに「低価格で高品質」を追求しています。これまでに紹介させて頂いた、ホワイトボックスサーバに加えホワイトボックススイッチや新たなストレージ装置を導入し、刷新されたインフラへ成長しています。今回は、インフラ担当としてのリリースまでの秘話をピックアップして紹介させて頂きます。

さらに進化したKCPS(Ver2.0)

KCOY_143_DC90500_S-800x533

システム設計のシンプル化

IaaSの設計におけるポイントは、どの様なステムがKCPS上で稼働するのか、どの様な特性をもったトラフィックが発生するのかなどの利用シーンが千差万別なため、柔軟性のあるシステム設計を心掛ける必要があります。しかし、柔軟性を持った設計は逆に複雑な設計となり障害時において影響範囲の拡大や、メンテナンス時の影響が広範囲となったりと、トレードオフの関係となりエンジニアを悩ませる課題となります。KCPS(Ver2.0)では、これまでの設計ノウハウや障害パターンから一つの答えを導き出しています。これも、数百システムが稼働しているKCPS(Ver1.0)の分析データから導き出したマニュアルにない答えでもあります。システム構成図を公開することは出来ませんが、誰が見ても惚れ惚れするシンプルな構成図になっています。KCPS(Ver2.0)の設計に込められた想いを少しだけ説明させて頂きます。

①フロントエリア、リソースエリヤ、バックヤードエリアを完全分離

1

IaaSを提供するには多種多様な機能をもった機器が必要となり、これらを繋ぐシンプルなネットワーク設計が最大のポイントです。そのため、各機器を3エリアに大きく分割しています。サービスを提供する管理系機器をフロントエリア、サーバやストレージなどのリソースを提供する機器をリソースエリア、システム全体を維持管理するバックヤードエリアで構成しています。これら、3エリアを東西リージョンで完全に分離し、マルチリージョン構成としています。これにより東西が完全に独立しているため、一方のリージョン(データセンタ)が震災等で被災した場合、残りのリージョンはサービスを継続利用することが可能です。また、同一リージョン内においても各エリア毎にネットワーク機器を物理的に分割しているため、単一障害で影響がでないことは勿論のこと、複数障害においても他エリアへの影響を発生させない構成となっています。全てのエリアにおいて機器が独立して配置されているため、メンテナンス時や障害時における影響範囲が極小化し「Quality Cloud」に繋がっています。

②ストレージコントロール

2

クラウドは通信だ!」というメッセージを出させて頂いてますが、クラウドにおいて「パフォーマンスはストレージだ!」というメッセージを出したいぐらい、仮想化環境におけるパフォーマンスを左右するポイントがストレージ設計にあります。複数のユーザが共用利用するCloud環境において、常に安定したストレージのパフォーマンスをいかに提供するかが、クラウド事業者としての課題です。KCPS(Ver2.0)においては、Rootボリュームストレージ、高速ストレージ、中速ストレージが全て別々のストレージ筐体に配置されています。さらに高速・中速ストレージにおいては、複数のストレージに分散配置することで可用性もさらに向上し、リソース管理やアクセスコントロールが容易となりました。

「ストレージのプロトコルは何を利用していますか?」と質問されることがあります。我々はアクセスパターンや障害時の切り替わり時間を考慮し、NFSとiSCSIの特徴を生かした混在利用をしています。重要なのは、何を利用するか?ではなく、何がベストなのか?なのです。NFSにおいては冗長構成における切替り時間が長いという課題がありますが、利用のしやすさやネットワーク影響を受けにくいというメリットがあり、iSCSIは手軽さはないものの、低レイアーでの処理のため負荷が低くエラーハンドリングがしっかりされるため高い信頼性があります。利用するポイント毎でのベストな選択をすることが重要なのです。それに加え、この構成をベースに何台のサーバを接続させていいのか?NW帯域はどれぐらい確保するのか?などの指標値を導き出し、システムの特性を深く理解し組み合わせていくのがシステム設計の面白いところです。これまでのKCPSにおける数千台規模の利用データからこの指標値を導きだし、最適な配置設計を行えるのが設計力であり、エンジニアの最大の腕の見せ所です。

KCPS(Ver2.0)におけるストレージ構成の最大のポイントとして、1仮想サーバで利用できるストレージキャッシュ量がこれまでに比べ大幅に増加しています。ストレージ性能指数にIOPSや遅延などの数値がありますが、この指標値を上げるには闇雲にSSDなどを搭載するだけではなく、Read/Writeキャッシュの使用量やヒット率をコントロールすることが、性能向上に一番効果的です。KCPSのストレージにおいては、1次キャッシュにDRAMを利用し2次キャッシュにSSDを利用することで大容量のキャッシュ領域を提供しています。キャッシュ設計で注意するポイントとして、Writeキャッシュの扱いがあります。Write処理においては、2次キャッシュを利用するよりも、1次キャッシュから直接DISK領域のSSDに書き込むほうが無駄な動きがなくパフォーマンスが向上します。そのため、1次キャッシュのWrite領域を多く確保し、2次キャッシュの利用量が減るようコントロールします。しかし、1次キャッシュ領域を過度に確保した場合、逆にパフォーマンスが低下してしまうのです。1次キャッシュには揮発性メモリーを利用しているため、コントローラ障害時にキャッシュデータが消失します。これを防ぐために、常に他方へキャッシュミラーを行う必要があります。キャッシュ領域を多く確保し過ぎると、ミラー処理に時間を要し逆にパフォーマンスが低下してしまいます。キャッシュ領域を適切に調整することで、高い性能を引き出すことが出来るのです。難しいですね!このように、インスタンスから最後のDISK領域までをトータルにコントロールすることがシステム設計において重要なのです。

キャッシュコントロールにおける最大の敵は、バースト的に発生するノイジーネイバーになります。KCPSにおいては、ノイジーネイバーが発生してもキャッシュの限界までIOをコントロールし、安定したパフォーマンスを提供出来るよう自動調整します。また、各ボリュームに対しMAX-IOPS制限を導入しています。利用者にはデメリットと思えるかもしれませんが、通常利用において問題となる制限値ではありません。このメリットとしては、複数のボリュームが高負荷状態に遷移したとしても、他のボリュームに安定したIOPSを提供出来ます。このMAX-IOPS値は、ストレージ装置固有の動きを分析し、分析試験の結果などからこのIOPS値を割り出しています。分析試験では実環境と同数のサーバを利用し、実環境に近いシナリオ試験を組み合わせ、導き出した値になります。公開出来る情報としてはここまでですが、安定した性能を提供するための対策がこれ以外にも多数施されています。本当は詳しい数値でご説明したいのですが、、、ここが我々の肝になりますのでこれ以上はお許し下さい。高性能ストレージの魅力を1インスタンスでも十分得られる設計になっていますので、是非体感してみて下さい!

③データ取得と監視

3

机上でいくら設計しても、実運用で期待通りに稼動し、利用しているお客様が満足出来ているかが一番肝心なことです。それには、監視において細かい性能値の取得をおこない、独自の閾値を用いて判定し、常に安定した性能を提供できるロジックを施す必要があります。一般的な性能値としてCPU稼動率やIOPSなどがありますが、機器や監視項目によって閾値の導き出し方がまったく違います。例えば、ストレージ機器にはコントローラ上にCPUやコアが複数搭載されており、コア単位で利用する用途や挙動が違うため個々に閾値を変える必要があります。しかし、機器標準のMIB情報ではコア単位での使用率がとれない機器もあり、コア単位で取得できるようカスタマイズを行っています。複数の機種を利用している場合、それぞれに専用の監視ツールがありますが(これ結構面倒ですよね)KCPSではそれらを一元管理することで、複合的な障害に対応しやすい監視設計にもなっています。問題にいかに早く気づき適切な対処をするためにも、細かい監視項目や指標値の取得が重要になります。そして、ここで蓄積した数値が次のシステム設計に必要な情報であり、システムの安定稼動を支えるベースとなっています。

終わりに

今回は大規模なクラウドのインフラ設計の裏側を少し紹介させて頂きました。公開出来ない部分が多いため、伝わりにくい個所もあったかと思います。しかしながら、クラウドのインフラの設計を公開している情報は少ないと思いますので、参考にして頂けたら幸いです。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
プラットフォーム技術部

加藤 真人

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP