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