Amazonのマイクロサービスとチーム

I Love APIs 2015 カンファレンスでのAmazonでのエンタープライズ分野でのスケールがどのように行われているかについての発表で、Chris Munns氏はマイクロサービスパターンはアプリケーションの作り方とチームの構造変え、マイクロサービスの開発と運用を成功させるにはチームの構造がとても重要だ、という。

AmazonでDevOpsビジネス開発マネージャを務める氏は、Wikipediaでのマイクロサービスの定義に言及しつつ、次の4つ制約を挙げる。

• 単一の目的
• API経由だけの接続
• HTTPSでの接続
• それぞれの間ではブラックボックスになっている

SOAとマイクロサービスを比べた場合、明確な違いがある。

Amazonのチームの大きさを説明した有名なふたつのピザチームは実際にはサービスチームと呼ばれ、自分たちで構築した“プリミティブ”を所有する。プリミティブとは、プロダクトの計画や開発、運用とクライアントのサポートワークなどだ。彼らは完全なオーナーシップと説明責任を持ち、毎日の運用とメンテナンスに責任を持つ。自分で作って、自分で運用するのだ。品質保証(QA)も運用もすべてひとつのサービスチームで賄われる。氏によれば、これらの役割を担う人は社内で共有される場合もあるそうだ。

チームはとても自由だが、大きな権限を与えられ、以下のような方法で高い水準を保たれる。

• 徹底的なトレーニング
• 20年を超えるスケールの経験から生まれたパターン&プラクティス
• ビジネスと技術の両面からの定期的なメトリクスのレビュー
• 社内の専門家による新しいツール、サービス、技術の共有

Amazonでの小さなチームとマイクロサービスの経験から培った重要な点を踏まえ、Munns氏は、同じ道を行こうとする会社に対して次のようなアドバイスを行った。

• 文化。協力してオーナーシップと説明責任を持つこと。大きなチームは普通、小さなチームよりも動きが鈍い。高水準の卓越さを要求するが、それをどのように実現するかは問わない。
• 実践。継続的統合(CI)と継続的デリバリ(CD)、運用のシンプルさの重要性
• ツール。CI、CD、インフラ管理、メトリクス、モニタリング、コミュニケーションのためのツールを用意する。

氏は最後にサービスとクライアントのパターンを確立することの重要性を強調した。通信や認証、セキュリティ、サービスディスカバリなどの基本的なパーツの再開発を避けるようにする。また、ビルド、ホスト、サービスのメトリクスを取得することの重要さを指摘する。インフラが期待した通りに動いているか、SLAは満たせているかなどを見つかるためだ。