どのようにAmazon、Netflix、Uber、Etsyがモノリスを打破し、マイクロサービスによって前例のない高みにまでスケールアップしたのか？
Amazon、Netflix、Uber、Etsyのように、世界中の企業の中で最も革新的で収益性の高い企業になるための大きな成功の一因がマイクロサービスの採用によるものもあります。
こういった企業は、モノリシック（一枚板）なアプリケーションを解体し、マイクロサービスベースのアーキテクチャにリファクタリングすることで、スケーリングの優位性、ビジネスの俊敏性、そして想像を絶する利益を短期間で達成したのです。
本記事では、大成功を収めた企業のマイクロサービスの過程を探りますが、その前に、企業がどんな状況に陥った時に最初にマイクロサービスについて考えるのか見てみましょう。
企業がマイクロサービスを採用する理由
ほとんどの企業は、インフラを単一のモノリス、または複数の緊密に相互依存するモノリシック・アプリケーションとしてデザインすることから始めます。モノリスは多くの機能を実行し、これらの機能のためのプログラミングは、すべてアプリケーションコードのまとまった部分にあります。
これらの機能のコードは織り込まれているため、解きほぐすのは大変です。モノリスの1つの機能を変更したり追加したりすると、アプリケーション全体のコードを混乱させる可能性があるため、アップグレードには時間とコストがかかることになります。アップグレードの回数が増えれば増えるほど、プログラミングはより複雑になり、アップグレードやスケーリングは事実上不可能になることが多いです。
マイクロサービスアーキテクチャの構築
この時点で、デベロッパーはモノリスの機能を、独立して動作する小規模なマイクロサービスに分ける選択ができます。 これらのサービスは、マイクロサービスベースのアプリケーション・アーキテクチャを形成するのに、APIを介してざっくり繋げられます。このアーキテクチャでは、各マイクロサービスを独立して開発、配置、拡張できるため、アジリティとプラガビリティが向上し、これは必ずしもサービス停止を引き起こすことなく、アプリケーションの他の部分に悪影響を与えることなく、また他のマイクロサービスをリファクタリングする必要なく、実行できます。
マイクロサービスアーキテクチャのデザイン手順は以下のとおりです：
1. モノリスを理解する
モノリスの動作を調べ、構成要素となる機能やサービスを決定します。
2. マイクロサービスの開発
アプリケーションの各機能を、主体的に独立して動作するマイクロサービスとして開発します。これらは通常、クラウドサーバー上のコンテナで実行され、各マイクロサービスは、検索、配送、支払い、会計、給与計算など、個々の機能に対応します。
3. 大規模なアプリケーションとの統合
マイクロサービスをAPIゲートウェイでざっくり統合し、それらが協調してより大きなアプリケーションを形成するようにします。Integrate.io API Managementサービスは、このステップで重要な役割を果たすことができます。
4. システムリソースの割り当て
Kubernetesのようなコンテナオーケストレーションツールを使って、各マイクロサービスのシステムリソースの割り当てを管理します。
このアプリケーションアーキテクチャの詳細については、マイクロサービス完全ガイドをご覧ください。
マイクロサービスの活用例
では、実際にマイクロサービスを導入している事例を見てみましょう。以下の企業は、マイクロサービスを使って、スケーリングやサーバー処理の重要な課題を解決しています。
1. Amazon
2000年代初頭、Amazonの小売ウェブサイトは、単一のモノリシックなアプリケーションのような動作でした。Amazonのモノリスを構成する多層サービス間、あるいはサービス内の緊密な接続により、デベロッパーはAmazonのシステムをアップグレードまたは拡張するたびに、依存関係を慎重に解かなければならなかったのです。
Amazon AWSの製品管理担当シニアマネージャーであるロブ・ブリガム氏は、以下のような状況を説明してくれました。
- 「2001年に遡ると、Amazonの小売サイトは大規模なアーキテクチャのモノリスだった。」
- 「誤解のないようにお願いします。これは複数の層で構成され、それらの層には多くのコンポーネントがあります...しかし、それらはすべて非常に緊密に結合され、一つの大きなモノリスのように動きます。現在、多くのスタートアップ企業や大企業のプロジェクトでさえも、このような形でスタートしますが、プロジェクトが成熟し、デベロッパーが増え、コードベースが大きくなり、アーキテクチャが複雑になると、モノリスはプロセスにオーバーヘッドを加えることになり、ソフトウェア開発ライフサイクルが遅くなり始めるのです。」（情報源）
2001年は、開発の遅れ、コーディングの課題、サービスの相互依存性により、Amazonは急速に拡大する顧客基盤の拡張要件を満たすことができませんでした。Amazonは、システムをゼロからリファクタリングする必要に迫られ、モノリシックなアプリケーションを、独立して動作する小規模なサービス別アプリケーションに分割しました。
以下はAmazonでの一例：
- デベロッパーはソースコードを分析し、単一の機能的な目的を果たすコードユニットを抜き出す
- そのユニットをWebサービスのインターフェースで包む
例：商品ページの「買う」ボタンを1つのサービスで開発、税金の計算機能を1つのサービスで開発したり、など。
Amazonでは、独立した各サービスのオーナーシップをデベロッパーチームに割り当てたことにより、少ないデベロッパーで1つのサービスに全力を注ぐことができるため、チームは開発のボトルネックをより詳細に把握し、より効率よく課題解決ができるようになったのです。
マイクロサービスをつなげて、より大きなアプリケーションを形成することについては：
「関数の単一目的化問題の解決のために、デベロッパーが守るべきルールとして、関数は独自のWebサービスAPIを通じてのみ、他の世界と通信できるようにしたのです。標準的なWebサービス・インターフェースに従う限り、これらのサービスは、サービス間の調整なしに、互いに独立して反復することができます」。（情報源）
Amazonの「サービス指向アーキテクチャ」は、現在の「マイクロサービス」と呼ばれているものの始まりでした。その結果Amazonは、Amazon AWS（Amazon Web Services）やApolloなどのマイクロサービス・アーキテクチャをサポートする数々のソリューションを開発し、現在それを世界中の企業に販売しているのです。マイクロサービスへの移行がなければ、Amazonが世界で最も価値のある企業（2020年2月28日の時価総額）にまで成長することはできなかったでしょう。
これはAmazonのマイクロサービスインフラ、通称「デス・スター」の2008年のグラフィックです：
2. Netflix
Smartbear Softwareは、「Netflixを出さずにマイクロサービスを語ることはできません。」と語っています。Amazonと同様、このマイクロサービスの例は、マイクロサービスという言葉が流行る前の2008年に始まりました。Netflixは2007年に映画配信サービスを開始しましたが、2008年にはサービス停止やスケールの問題に悩まされ、3日間、会員にDVDを発送できない事態が発生しました。
Netflixによると:
Netflixのクラウドへの移行は、2008年8月にデータベースが破損し、3日間会員へのDVDの発送ができなくなったことから始まりました。その時、私たちはデータセンター内のリレーショナルデータベースのような垂直スケールの単一障害点から、クラウド内の高信頼性、水平スケーラブル、分散システムに移行する必要があることに気づきました。クラウドプロバイダーとしてAWS（Amazon Web Services）を選んだのは、最大のスケールと幅広いサービスや機能を提供できるからです。（情報源）
2009年、Netflixはモノリシックなアーキテクチャを、サービスごとにマイクロサービスにリファクタリングするプロセスを徐々に開始しました。最初のステップは、顧客向けでない映画制作のプラットフォームを、独立したマイクロサービスとしてAmazon AWSのクラウドサーバー上で使えるように移行することでした。Netflixは、その後2年間かけて顧客向けのシステムをマイクロサービスに変換し、2012年にそのプロセスを完了させました。
下記は、Netflixが徐々にマイクロサービスへ移行していく様子を図にしたものです：
マイクロサービスへのリファクタリングにより、Netflixはスケーリングの課題とサービス停止を克服することができました。2015年までに、NetflixのAPIゲートウェイは、500以上のクラウドホスティングされたマイクロサービスによって管理され、毎日20億のAPIエッジリクエストに対応できるようになりました。2017年までには、そのアーキテクチャは700以上の疎結合マイクロサービスで構成されるようになり、現在は、Netflixは190カ国の1億3900万人以上の加入者に毎日約2億5000万時間のコンテンツを配信しており、今も成長を続けています。
こちらが2007年から2015年までのNetflixの成長ぶりを描いたものです：
しかし、それだけではありません。Netflixはマイクロサービスによって、コスト削減という別のメリットも得ました。ストリーミング開始あたりのクラウドコストは、結局、データセンターでのコストの数分の一になりました。
こちらはNetflixのマイクロサービス・アーキテクチャを自信を持って披露する、Netflixシニアエンジニアのデイブ・ハーン氏です。
3. Uber
このマイクロサービスの例は、ライドシェアサービスのUberの立ち上げから間もなく、そのモノリシックなアプリケーション構造に関連する成長のハードルに遭遇したときに生まれました。このプラットフォームは、新しい機能の効率的な開発、立ち上げ、バグ修正、急速成長するグローバル運営の統合に四苦八苦していました。さらに、Uberのモノリシックなアプリケーション・アーキテクチャは複雑であるため、デベロッパーは既存のシステムを操作した経験が豊富でなければならず、システムのマイナーアップデートや変更を行うだけでも大変でした。
当時のUberのモノリシックな仕組み：
- REST APIを通じてUberのモノリスにつながる乗客とドライバー
- 請求、支払い、テキストメッセージなどの機能のAPIを組み込んだ、3つのアダプター
- MySQLのデータベース
- すべてモノリスの中に含まれていた機能
Dzoneに掲載されているUberオリジナルのモノリスの図です：
Uberは、既存のアプリケーション構造の課題を克服するために、モノリスをクラウドベースのマイクロサービスに分割することを決定しました。その後、デベロッパーは乗客管理、道のり管理などの機能のために個々のマイクロサービスを構築し、上記のNetflixの例と同様に、UberはAPI ゲートウェイを介してマイクロサービスを接続しています。
Dzoneに掲載されているUberのマイクロサービス・アーキテクチャの図です。
Uberがアーキテクチャ様式移行によって得たメリット：
- 特定のサービスの明確なオーナーシップを個々の開発チームに割り当てることによる新規開発のスピード、品質、管理性の向上
- 拡張が必要なサービスだけに集中できるようにすることによる迅速な拡張の促進
- 他のサービスに影響を与えることなく、個々のサービスの更新が可能
- より信頼性の高いフォールトトレランスを実現
ただし、問題がありました。モノリスをマイクロサービスにリファクタリングしただけでは、Uberのジャーニーは終わらないのです。UberのSREであるスーザン・ファウラー氏によると、マイクロサービスのネットワークは、明確な標準化戦略を必要とし、そうでなければ 「制御不能に陥る 」危険性があるといいます。
このテーマで行われたファウラー氏の講演のまとめ
「ファウラー氏がマイクロサービスのパターンを適用し、信頼性と拡張性を向上させる方法を調査し始めたとき、Uberには約1300のマイクロサービスがありました。彼女はマイクロサービスを標準化するプロセスを開始し、これによりUberは、サービス停止などの混乱もなく、大規模なハロウィンラッシュを乗り切ることができたのです。ファウラー氏は、「Uberには何千ものマイクロサービスがあります。古いものもあれば、もう使われていないものもあり、それも問題になりました。それらを確実に切り離して整理するには、多くの労力が必要です。」 （情報源）
ファウラー氏によると、Uberの標準化に対する最初のアプローチは、各マイクロサービスのローカルスタンダードの作成だったそうです。これは、マイクロサービスを軌道に乗せるのに当初はうまくいきましたが、Uberは、標準の違いにより、個々のマイクロサービスがアーキテクチャ内の他のマイクロサービスの可用性を常に信頼できるわけではないことに気づいたといいます。デベロッパーがあるマイクロサービスを変更すると、サービス停止を防ぐために他のマイクロサービスも変更しなければならないのが普通でした。これは、変更後にすべてのマイクロサービスの新しい標準を調整することが不可能だったため、スケーラビリティに支障をきたしました。
結局、Uberはすべてのマイクロサービスに対してグローバルスタンダードを開発することにしました。その方法は以下の通りです：
- まずは、耐障害性、文書化、性能、信頼性、安定性、スケーラビリティなど、可用性をもたらす原則の分析
- 次に、これらの原則を定量化できる基準を設け、Webページの閲覧数などのビジネス指標を見ることで測定の実現
- それから、メトリクスの「マイクロサービスでの1秒あたりのリクエスト数 」への変換
ファウラー氏によると、このようなマイクロサービス・アーキテクチャのグローバルスタンダードを開発・実装するのは長いプロセスですが、ファウラー氏にとっては、グローバルスタンダードの実装が、Uberのスケーリングの問題を解決するパズルの最後のピースだったことから、それは価値があることでした。
こちらは2019年のUberのマイクロサービス・アーキテクチャの図です。
4. Etsy
Etsyがマイクロサービスベースのインフラに移行したのは、eコマースプラットフォームでサーバーの処理時間の短さが原因となるパフォーマンスの問題が発生し始めたことがきっかけでした。同社の開発チームは、「1,000ミリ秒のTime-to-Glass（ユーザーの端末で画面が更新されるまでの時間）」まで処理を短縮することを目標に掲げ、その後、Etsyはこの目標を達成するには、同時実行トランザクションが処理時間を高める唯一の方法であると判断しました。しかし、PHPベースのシステムの制限により、APIの同時呼び出しは事実上不可能だったのです。
Etsyは、一連の低迷期から抜け出せませんでした。それだけでなく、デベロッパーはEtsyの新しいモバイルアプリの機能のために、プラットフォームの拡張性を高める必要がありました。こういった課題解決のために、APIチームは、開発チームにとってAPIがなじみやすく、アクセスしやすい状態を維持する新しいアプローチのデザインが必要でした。
インスピレーションを導く
Netflixや他のマイクロサービス採用企業からヒントを得て、Etsy はメタエンドポイントを持つ 2 層のAPIを実装しました。それぞれのメタエンドポイントは、追加のエンドポイントを集約しており、より技術的になることを覚悟で言えば、InfoQはこの戦略によって「低レベルの汎用リソースをデバイスまたはビュー固有のリソースにサーバーサイドで合成する」ことが可能になっり、以下のような結果になりました：
- フルスタックによる多段ツリーの作成
- 同時進行するメタエンドポイントのレイヤーの消費による顧客向けウェブサイトとモバイルアプリの、カスタムビュー構成
- 並行するメタエンドポイントによるアトミックコンポーネントのエンドポイントの呼び出し
- データベースと通信する唯一のものは、最下層の非メタエンドポイント
この時点では、並行処理の不足がまだEtsyの処理速度を制限していました。メタエンドポイント層は、ウェブサイトとモバイルアプリのカスタムバージョンを生成するプロセスを簡素化し、高速化しましたが、複数のメタエンドポイントの連続処理は、Etsyのパフォーマンス目標を達成する上でまだ障害になっていました。
最終的にエンジニアリングチームは、cURLを使用してHTTPの並列呼び出しを行うことで、APIの並列化を実現しました。これに加えて、彼らはカスタムEtsy libcurlパッチを作成し、ネットワーク上を移動するリクエストのコールヒエラルキーを表示する監視ツールも開発しました。さらに、EtsyはAPIの周囲にデベロッパー向けの様々なツールを作成し、デベロッパーの負担を軽減し、その2層APIの採用を加速させました。
Etsyは2016 年にこのアーキテクチャスタイルを採用して稼働しました。その後、継続的なイノベーション、同時処理、より速いアップグレード、容易なスケーリングをサポートする構造から恩恵を受けるこの企業は、マイクロサービスの成功例として挙げられます。
Etsyのソフトウェアエンジニアであるステファニー・シルマー氏のプレゼンテーションから、Etsyのマルチレベルツリーを描いたスライドを紹介しておきます。
Integrate.io API Managementサービス：マイクロサービスアーキテクチャの高速接続のためのREST API自動生成ツール
上記のマイクロサービスの例を読むと、モノリシックなアプリケーションを壊してマイクロサービス・アーキテクチャを構築することの利点、プロセス、課題を理解することができるはずですが、このアーキテクチャスタイルを構成する個々のマイクロサービスを接続するためのカスタムAPI開発の時間と費用については、ここでは触れていません。そこでIntegrate.io API Managementサービス（iPaaS）の出番です。
Integrate.io API Managementサービス（iPaaS）は、マイクロサービス・アプリケーション・アーキテクチャを統合するためのAPIの開発と公開のプロセスを簡素化するポイント＆クリックのノーコードインターフェースを提供しています。
データ統合プラットフォームであるIntegrate.io内では、企業はクラウド上でデータの統合、処理、分析のための準備を行うことができます。コードや専門用語を有しなくても使用できる環境であるため、ハードウェア、ソフトウェア、または関連インフラに投資することなく、どのような組織・個人でもビッグデータがもたらす機会をご享受頂けます。
14日間無料トライアル、無料デモやご相談は、こちらのリンクよりリクエストをお願い致します。
