Amazonの社風とSOA

https://plus.google.com/app/basic/stream/z12ld3fwhlnexv5b004cjv0oapmuflzrezc0k

1 comment | 3 points | by WazanovaNews 約3年前 edited


Jshiike 約3年前 edited | ▲upvoteする | link

Steve Yegge (Amazon -> Google)が、Googleのプラットフォーム戦略が遅れていることを指摘した、2年前のかなり長いエントリーですが、その中で触れているAmazon時代のエピソードが興味深かったです。

Jeff Bezosは2002年の当時からプラットフォーム戦略の重要性をよく理解していたが、とにかくマイクロマネッジメントで強制力のある経営者だったとして、サービス指向アーキテクチャ(SOA)の採用を指示したときのエピソードを取り上げてます。

そこでJeffは命令をだした。もちろんこれはいつものことだが、これが起きると人々は鎚でたたかれたかのように、アリのごとくスクランブルする。…Anyone who doesn't do this will be fired….という指示は文字通りで、本当にクビになることがわかってるので皆は仕事に取りかかる。進捗の監視役にアサインされた最高チーフ熊ブルドッグのRick Dalzellは、陸軍のレンジャー部隊出身、West Point Academy(陸軍士官学校)卒、元ボクサー、Walmartの元チーフ拷問人兼CIO、とにかくでかくて愛想がよくて恐ろしい…皆はとにかくたくさんの進捗報告を用意してRickの耳に入るように頑張る。

それから数年かけてSOAに移行完了し、大きな成果を得ますが、一方でAmazon規模のサービスになると解決すべき課題もかなり抱えたとしてます。

  • 緊急アラートをどこにエスカレーションすべきか判断しづらくなった。障害の本当の原因のサービスが特定される前に、障害のチケットが20本のサービス間コールで行き来してしまうかもしれない。大量のメトリックスの仕組みを構築しない限りは、最初のチームでレスポンスタイムが15分かかると、最終的な根本原因のサービスのチームに行きつくまでには数時間かかるかもしれない。

  • 同僚のどのサービスのチームもDOS攻撃者になる可能性がある。サービスごとの調整基準がしっかり決まってないと、正確に次のステップを判断できない。

  • 監視とQAも同じこと。しかし、本当に大規模なSOAを経験するまではわからない。自分の担当しているサービスのシステムが「はい。大丈夫です。」と言ったとしても、実は本当に大丈夫なのは「大丈夫です。ラジャー、ラジャー、オーバー。」とロボットの声を返す小さな機能だけなのかもしれない。サービスが実際にレスポンスを返しているかどうかは、個別にコールをして確認しなくてはいけない。監視システムがサービスとデータ全体を網羅的にチェックするようになるまでは、問題は繰り返し起きる。

  • サービスが週百件あり、他のサービスと通信しなくてはいけないコードがあれば、サービスディスカバリーのメカニズムがないとできない。また、サービスディスカバリーは、サービスレジストリという別のサービスをつくらないと成り立たない。そこでAmazonは、サービスレジストリをつくり、プログラム的にサービスを見つけ、APIは何か、現在の状況はどうかを確認できるようにした。

  • 他人のコードをデバッグするのは相当大変になる。デバッグ用のサンドボックスで各サービスを実行できるような仕組みがないと不可能。

  • サービス間で仕事をやっていく過程で皆が学んだのは、外部のベンダーを信用しないのと同じように、お互いのサービスのことを信用しないということ。

「2005年にGoogleに転職する時点でAmazonの改善の取り組みはまだ道半ばだったが、かなり進んでいた。」とのことですので、時間をかけて解決していったと推察されますが、これだけの規模のSOAだと確かに簡単にバラ色の結果とはならないんでしょうね。


Airbnb: ユーザに最適な検索ロジックを徹底的に深堀りして考える


#amazon #google #SOA

Back