大井です。間隔があいてしまいましたが、Qcon SFレポートの続きです。

Qconでは、cloudとは？なぜcloud?という話はとうに過ぎていて、「Cloudをどこでどのように使うか」と話に、言うなればmemcacheやDB同レベルの「サービス」として捉えた言及が行われていました。

これだけでも未だ「クラウドとは何か」「コスト削減」「安全なの？」ばかり言われている日本より数歩も先に進んでいる印象。

そして２日目のキーノートでは、このクラウド時代に人はどのように変化していけばいいのか、というようなことを、eBayのチーフエンジニアRandy Shoupさんが"Being Elastic ~Evolving Programming for the Cloud~"という題で講演しました。非常に印象的なセッションでしたので紹介します。

Developers Must Adapt

多少の制約はあるのは事実だが、得られる利益は巨大なので、開発者は必ず適応すべき。

この制約というのは、スケーラブルなインフラ効果的にするには、アプリケーションも、開発の慣例も、カルチャーもスケーラブルでなければならないし、クラウドに適応するということは、アーキテクチャやアジャイル、DevOps等あらゆる幅広い話題が必然的に入ってくることであり、制約、というよりは開発者はジェネラリスト的素質が必要になるということのようです。

Programming in the Cloud

クラウドで開発するときの重要な要素として

• Parallelism
• Layering
• Services
• State management
• Data model
• Failure handling
• Testing

の７項目が必要。

Parallelism

シンプルなパラレルアルゴリズムを考えておくことで、スケールアウトしやすくなる。リソースを分配したりelasticに使う場合はパラレルであることが必須になる。

ここでは、リニアである必要のある処理とその必要がない処理と分ける、という意味もあるようです。MapReduceは明らかに後者の処理ですよね。

Layering

適切にLayeringしておくことが必要、特にクラウドではきれいにレイヤー化しておくことが重要になります。

基本的にはソフトウェア・システムコンポーネント単位でレイヤー化する感じですが、設定系と機器系、エラー管理は共通のレイヤーとしてまとめます。

Service

システムを機能毎にサービスとしてまとめていく。ポイントは、シンプル、1目的、ステートレス、マルチインスタンス。

• 単純な構成から複雑な振る舞いを実現するようにする。
• サービス間はそのインターフェースに依存し、実装に影響が無いようにする。
• サービス間のアクセスはIPアドレスではなくURIで。

“Make everything as simple as possible, but not simpler.”– Albert Einstein

State Management

インスタンスは短命だし、ローカルのメモリやストレージは高速だがインスタンス間で不一致を引き起こすので、依存しないためにも各インスタンスはステートレスにする。

Key‐Value Data Model

KVSは単純で水平スケールするので適しているが、逆に複雑な関連付けや固定したスキーマは困難。joinやソート、バリデーション等アプリケーション側の仕事が増える。

なので、読み書きのスループットをあげるためにパラレルで読み書きさせたり、非同期な更新処理を走らせたり、あらかじめjoinやsortした結果を突っ込むような使い方が適している。

Failure Handling

これが発生する場合、タイムアウトやリトライ、多くのデグレが発生している等を意味している。それが発生する前提のハンドリングを考える。

Testing

テストドリブン、テストファーストのアプローチはとりわけクラウドでうまくいく。自動テストは不可欠。

“In the data center, robust code is best practice. In the cloud, it is essential.”

– Adrian Cockcroft

Operating in the Cloud

クラウドでの運用で重要になる要素として以下の５つに言及されていました。

• DevOps Mindset
• Configuration Injection
• Instrumentation
• Monitoring
• Metering

DevOps Mindset

クラウドでは開発者と運用者を行ったり来たりするので、全員がデプロイやモニタリングツールを使い、全員がシステムの責任を共有することになる。開発担当、運用担当という業務分掌はナンセンス。DevOpsという言葉が最近でてきましたが、クラウド時代ではこれが必須マインド。

例えば徹底した自動化にもそれが表れます。クラウドでは構築やdeployが頻繁におき、またスケーリングも頻繁におきます。全員が開発も運用もやり、それを頻繁に…ということになると、自ずと自動化をして省力化したり、管理ツールをまかない飯的に自分たちで作ったりしていくと思います。

Configuration Injection

（すみません、これよく分からなかったのでスキップ）

Instrumentation

デバッガやプロファイラはアタッチせず、リモートからするようにして、モニタリング疲れを避ける。

Monitoring

コンポーネント間のフローを含めて全てをモニタリングし、典型的な（平常の）システム動作を理解することで、何が異常かがすぐに分かる。

Metering

固定費から変動費になる。クラウドは、節約したところがダイレクトに結果（コスト）に反映されたりするので、エンジニアがDevOpsの範囲を超えて経営まで意識することになる訳ですね。

進化論と一致

セッションの〆として、ダーウィンの進化論を引き合いに出していました。

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”

…変化しなければ生き残れないのです。