読者です 読者をやめる 読者になる 読者になる

aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。1年以上古いエントリは疑ってかかってください)

訳:SWF: RightScale でのオーケストレーション事例 by Amazon SWF

RightScale Server Orchestration and Amazon SWF launch | RightScale Blog

http://blog.rightscale.com/2012/02/22/rightscale-server-orchestration-and-amazon-swf-launch/

超意訳

====

 Amazon SWFのリリース (Wernerのブログも参照のこと)は、我々が手がけている新しい自動化機能について語る良い機会であり、来るべきリリースを提示するだろう。我々はすでに数カ月の間、サービスのバックエンドでSWFを使っており、SWFはオーケストレーション機能の開発をものすごく加速させる極めて素晴らしいサービスである。個人的には、自動化は、クラウドコンピューティングにおいて最も基本的な進化と思う。自動化によって、すべてのビジネス的な利便性( 従量課金pay as you go, scale on demand, 弾力性 resiliency,予測精度 predictability,etc) が可能になり、サービスの信頼性を向上させるために計算資源をスケールできル用になる。クラウドコンピューティングは全スタックを通して自動化無くては信じられない(inconceivable)。

RightScaleは最初から自動化に注力してきた。早期から、CPU負荷等のモニタリングメトリクスに基づいて自動的にサーバを起動・終了するオートスケールを提供している。理解できていない新人の多くは、CPU負荷が高くなってからサーバ追加のコールをする。難しいのは、新しいサーバを用意するために全ての手順を行うことだ。その中には、必要な全てのソフトェあをロードし、すべてを設定し、ロードバランサやデータベース等の別のサーバと接続することを含んでいる。これこそが、RightScaleの機能の大部分が、本番環境のアプリケーションにおける構成管理や完全自動ブートに関連していることの理由である。

次のリリースで、このプラットフォームの頂上を構築し続け(we are continuing to build on top of this platform )、サーバーオーケストレーションを紹介する。サーバーオーケストレーションはワークフロー言語という、サーバやデプロイ等のRightScaleリソースのレベルで自動化を可能にする言語を使う。我々が実装した最初の機能は、オートスケールの次の3つの部分をカスタマイズ可能にすることである。(1)いつスケールアップ・ダウンをするか?何台に対して行うか?を決める、(2)新しくサーバを起動する、(3)既存サーバを終了させる。

仕組みは、サーバ群を何台スケールアップ・ダウンさせるべきか?にを知るために、1分間隔で、ユーザ定義の決定関数をRightScaleシステムが呼び出している。決定関数は、何台サーバを増やすか?(値>0)、何台サーバを終了させるか?(値<0)、サーバ台数を維持するか?(値=0)という整数を単純に返す。決定関数は我々のAPIを使ってモニタリングデータを取得可能で、ビルトインもしくは完全に異なる計算が可能である。要求精度を向上させるためにアプリケーション固有の状態とメトリクスについての知識を使う、興味深い例がある。flashイベントが近づいていることと、大量のサーバを一度に起動する必要があるといえるかもしれない(You may be able to tell early that a flash event is coming and that you need to launch a large number of servers all at once.)。これはひとつの例で、空は本当に制限され、この領域では我々の顧客が素晴らしいアイディアを持っていることを知っている。

決定関数がより多くのサーバを要求すると、実際にサーバを起動するために、RightScaleはスケールアップのワークフローを実行する。これは、サーバの起動方法を制御し、サーバ起動時に慎重に管理する興味深い機会を創ることになる。例えば、可用性の理由で、データセンター数カ所に等しくサーバーを広げたいかもしれない。もしくは、最も安い場所で起動したいかもしれない。同様に、スケールダウンのワークフローも、どのサーバを終了させるか選ぶ。ビルトインのオートスケーリングでは、最も古いサーバーを終了させ、実行中のサーバを新しい状態に保つようにする。しかし一部のアプリケーションでは、最も新しいサーバーを終了させることが望ましい。加えて、スケールダウンワークフローはアプリケーションを正常に(gracefully)シャットダウンし、バックアップを取得し、ログファイルを退避させてからサーバを終了させることができる。

オーケストレーション機能を設計する際、2つの重要な要件を置いていた。並行性(concurrency)と耐障害性(fault tolerance)だ。多くのサーバーを操作する際に実時間内にタスクを完了させる唯一の方法として、並行活動を表現する必要があるからだ。例えば、多くのサーバーに対してローリングアップデートを行うには、オーケストレーションはあるサーバ群に対して、それらに並列にアップグレード処理を行い、次のサーバ群に移る。

オーケストレーションが本当に興奮するのは、異なるデータセンターやクラウドでもどうにか、障害からの復旧と故障リソースの自動再作成を行うの時である。オーケストレーションプロセス自体の弾力性(resiliency)について、次のような質問がすぐに上がる。「同一の広域障害で影響を受けた場合に、リカバリできないのではないか?」長時間オーケストレーションプロセスが実行される場合も同様の関心事があがる。前述のオートスケールの例は、永久に実行し続け決定関数を呼び出すワークフローと、定期的に子ワークフローを呼び出すように実装されている。

並行性の良いサポートを提供するためと、耐障害性の高い実行環境を用意するために、我々はオーケストレーションシステムを、オープンソースRuoteワークフローシステムで構築されたワークフロー言語をベースにすることを決めた。

Ruoteは多くのとても優れた構造化並行構築(structured concurrency constructs)を提供する。例えば、「同時に(concurrently)実行し、全て完了するまで待ち合わせろ」や「同時に実行し最初の終了まで待ち、残りはキャンセルしろ」といった戦略を表現できる。後者は聞きなれないが、リソースが必要で複数の手段(avenues)を試して最初に成功したリソースを拾いたい場合に便利である。

Amazon SWFは、Routeワークフローの耐障害性実行を、手軽に行える。我々は、複数のアベイラビリティゾーンにまたがって分散している多くのサーバから実行されるワークフローの結果から、実行のバックエンドとして、RuoteからAmazon SWFに対称を変更した。SWFはワークフローアクションの実行スケジューリング、結果の収集に気を使うい、アトミックに結果をRuoteに戻すので、次のアクション群をスケジュールできる。その結果は、大規模な障害に直面してもワークフローを継続実行できるとても弾力のある(resilient)オーケストレーションシステムである。

我々は明らかに新しい機能について興奮しており、顧客に使ってもらうのを待てない。Amazon SWFがある今なので、我々は最後の仕上げの最中で、来るべきリリースの後すぐにプライベートBetaを準備したい。もし早期アクセスに興味があるなら、メールを送ってほしい。