導入文
中央集権的な多層アーキテクチャが単一のコードベースでアプリケーション全体を作成していたモノリシック時代に開発されたアプリケーションで、あなたの組織がまだ窮地に立たされているだろう。
このクライアントサーバモデルは、デスクトップがITを支配していた時代には優れた選択でした。しかし、モバイル・デバイスやクラウドの台頭により、バックエンドのデータは常に幅広いデバイスで利用可能でなければならなくなり、モノリシックなアーキテクチャでは、変更が加えられるたびにアプリケーション全体を更新しなければならず、機能を追加したり新しいコンテキストに対応しようとするたびに新たなバグが発生する可能性が出てきます。さらに悪いことに、すべてが単一のコードベースに縛られているため、特定の機能やサービスをスケールアップすることができず、アプリケーション全体をスケールアップしなければなりません。
マイクロサービス では、コードは独立したサービスに分割され、別々のプロセスとして実行されます。サービスからのアウトプットは、独立した通信サービスのオーケストレーションの中で、別のサービスへのインプットとして使われます。マイクロサービスは、アプリケーションがサポートするデバイスの種類をあらかじめ想定していない企業にとって特に有用です。
企業は マイクロサービス により、
- ウェブ
- モバイル
- IoT
- ウェアラブル
- フィットネストラッカー環境
さまざまなプラットフォームで一貫したユーザー体験を提供するアプリケーションを開発できます。Netflix、PayPal、Amazon、eBay、Twitterは、現在マイクロサービスを使用している企業のほんの一例です。
マイクロサービス とは
マイクロサービス（microservice）または マイクロサービス・アーキテクチャ」とは、クラウドネイティブなアーキテクチャのアプローチであり、1つのアプリケーションを、独立してデプロイ可能な多数の小さなコンポーネント（サービス）で構成する方法です。
マイクロサービス の特徴は下記の通りです。
- データベースとデータ管理モデルを含む独自のテクノロジー・スタックを持つ。
- REST API、イベント・ストリーミング、メッセージ・ブローカーを組み合わせて互いに通信する。
- サービス間の境界線は、しばしばコンテキスト境界と呼ばれる。
マイクロサービス に関する議論の多くは、アーキテクチャの定義や特徴を中心に回転してきていますが、その価値は、極めて単純なビジネスや組織の利益を通じて、より一般的に理解することができます。
- コードをより簡単に更新できる 。 アプリケーション全体に影響を与えることなく、新しい機能や特徴を追加できる。
- チームは、コンポーネントごとに異なるスタックや異なるプログラミング言語を使用できる。
- コンポーネントは互いに独立してスケーリングできるため、1つの機能の負荷が高すぎるためにアプリケーション全体をスケーリングしなければならないことに関連する無駄やコストを削減できる。
モノリシックサービス とは？
モノリシック システム は、単一のブロック で構築されます。このようにしてモノリシック アプリケーションが構築され、API、データベース、サービス、ロード バランサーなどが単一のアプリケーション フレームワークに組み込まれた 1 つのエンティティとして機能します。 一方、マイクロサービスは、アプリケーションの各側面を独立したサービスに分割し、API を介して通信します。通常、個々のチームが各サービスを担当します。
以下のような特徴を持つプロジェクトに取り組んだことがありますか?
- 数か月ごとにリリース。
- 幅広い範囲をカバーする機能と機能を備えている。
- チームの規模が大きい。
- デバッグが大きな課題となる。
- 新しい技術を適用することの難しさ。
以上がモノリスアプリケーションの特徴です。
モノリス アプリケーション は通常非常に大きく、コードのサイズは通常 100,000 行を超えます。場合によっては、コードが 100 万行を超えることもあります。
モノリス (1 ブロック) アーキテクチャに従ってソフトウェアを構築する場合です。すべてのモジュール (ビュー、ビジネス、データベース、レポート) は 1 つの大きなプロジェクトにグループ化されます。デプロイ時に、このコードのブロックをサーバーにスローし、実行するように構成します。
モノリスアーキテクチャはシンプルでコーディングが簡単であり、小規模なシステムでは効果的ですが、複雑なソフトウェアになると欠点が浮き彫りになります。モジュールが一つにまとめられており、モジュールをアップグレードする場合は全体のコードを再デプロイする必要があります。そのため、エンドユーザーはデプロイ中にシステムの機能を使用できなくなる可能性があります。また、多くのユーザーにサービスを提供する場合は、サーバーをアップグレードする必要が生じるでしょう。
モノリスアプリケーション の課題
- アプリケーションの拡張性や変更の柔軟性が低い
- アプリケーション間の依存性が高く、更新が複雑
- アプリケーションが密に結合されており、全体に影響を及ぼす
- 更新のたびに、アプリケーションを再デプロイする必要がある
マイクロサービス と モノリシック アーキテクチャ の比較
モノリシック アーキテクチャと マイクロサービス に関しては、新しい方が優れていると考えがちです。ただし、モノリシック アプリケーションと マイクロサービス の問題は、単に古いか新しいかという問題よりも少し複雑です。
必要なものに応じて、モノリシック アーキテクチャまたはマイクロサービス アーキテクチャが組織の可能性を引き出す鍵となる可能性があります。
それぞれのメリットとデメリットを比較して詳しく見てみましょう。
| マイクロサービス | モノリシック | |
| 導入 | システム全体のシンプルかつ迅速な開発 | 個別のリソースが必要なため、展開の調整が複雑になる |
| スケーラビリティ | 新しい変更を維持したり処理したりするのは困難である。システム全体を再展開する必要がある | 各要素はダウンタイムなしで個別にスケーリング可能 |
| 機敏 | 柔軟性に欠け、新しい技術、言語、フレームワークを採用することができない | ビジネス目的を解決するために新しいテクノロジーと統合する |
| 回復力 | 1 つのバグや問題がシステム全体に影響を及ぼす可能性があります | 1 つのマイクロサービスで障害が発生しても、他のサービスには影響しない |
| テスト | エンドツーエンドのテスト | 独立したコンポーネントは個別にテストする必要がある |
| 安全 | ユニット内の通信によりデータ処理が安全になる | プロセス間通信には API 回避が必要であり、セキュリティ上の問題が発生する |
| 開発者 | 分割不可能な巨大なデータベースのため、チームの努力を分散することが不可能 | 開発者のチームはダウンタイムなしで独立して作業できる |
マイクロサービス に欠かせない技術
最新のツールや言語であれば、どんなものでもマイクロサービス・アーキテクチャで使うことができるが、マイクロサービスにとって不可欠で、定義に近いコア・ツールがいくつかあります。
コンテナ、Docker、Kubernetes
Dockerについて語るには、まずコンテナについて触れなければなりません。コンテナは、アプリケーション開発のライフサイクルにおける重要な問題を解決します。開発者はコーディングの際、自分のローカル開発環境で作業します。そのコードを本番環境に移す準備ができたとき、新たな問題が発生します。コードは自分のマシンでは完璧に動くが、本番環境では動きません。この問題には多くの理由があり、オペレーティングシステムの違い、依存関係の違い、ライブラリの違いなどがあります。
Dockerは現在最も人気のあるコンテナ・プラットフォームです。Dockerは適切なタイミングで市場に登場し、最初からオープンソースであったため、今日の市場で圧倒的な地位を占めています。現在、企業の30％がAWS環境でDockerを使用しており、その数は増え続けています。
Docker と Kubernetes: オーケストレーション システムの必要性
Docker はコンテナ アプリケーションのパッケージ化と配布のためのオープン スタンダードを提供しますが、新たな問題が発生しています。これらすべてのコンテナはどのように調整され、スケジュールされているのでしょうか? サービスを中断せずにアプリをシームレスにアップグレードするにはどうすればよいでしょうか? アプリケーションの状態を監視し、何か問題が発生したことを認識し、適切なタイミングで再起動するにはどうすればよいでしょうか?
コンテナを配置するためのソリューションがすぐに登場しました。Kubernetes、Mesos、および Docker Swarm は、大きなマシンのように動作するマシンのクラスターを作成する抽象的な方法を提供する人気のあるソリューションの一部であり、これは大規模な環境で重要です。
実際のところ、実稼働環境でコンテナを管理するのは簡単ではありません。コンテナにはディスパッチシステムが必要です。
では、派遣システムは何をする必要があるのでしょうか？
- 多数のコンテナとユーザーを同時に処理します。アプリケーションには、同時に相互にやり取りする何千ものコンテナとユーザーが存在する可能性があり、これらのやり取りを管理および追跡するには、その目的のために特別に設計された包括的なシステムが必要です。
- 監視サービスと、コンテナとユーザー間の通信を管理します。ユーザーはどうやってコンテナを見つけて連絡を取り続けるのでしょうか? 各マイクロサービスにサービス監視用の独自の組み込み機能を提供することは反復的であり、非効率的になる可能性があります。実際、パフォーマンスが許容できないレベルまで低下したり、大規模な輻輳が発生したりする可能性があります。
- 効率的な負荷分散。アドホックで調整されていない環境では、コンテナの負荷はその時点でのユーザーのリクエストに大きく基づいている可能性があり、サーバー レベルでの負荷の不均衡や非効率的な割り当てなどが発生し、コンテナの可用性が制限される可能性があります。システムリソース。負荷分散は、効率的な順序付けとリソース割り当てを提供することで、この問題を解決するのに役立ちます。
- 認証とセキュリティ。Kubernetes のようなオーケストレーション システムを使用すると、(アプリケーションではなく) インフラストラクチャ レベルで認証とセキュリティを簡単に処理し、すべてのプラットフォームに一貫したポリシーを適用できます。
- クロスプラットフォームの展開。オーケストレーターは、コンテナー操作のオーケストレーション、マイクロサービスの可用性、クロスプラットフォームのマルチクラウド環境での同期など、他の複雑なタスクの管理に役立ちます。
オーケストレーション システムは、コンテナ ベースのアプリケーションの動的で包括的なインフラストラクチャとして機能し、外部とのやり取りを管理しながら、保護された高度に組織化された環境で動作できるようにします。
Kubernetes はこのタスクに適しており、これが Kubernetes が非常に人気になった理由の 1 つです。
APIゲートウェイ
マイクロサービス は、特に最初に状態を確立するときに、APIを介して通信することが多いです。クライアントとサービスが互いに直接通信できるが、特にアプリケーションのサービス数が時間の経過とともに増えてくると、しばしば有用な仲介レイヤーになります。APIゲートウェイは、リクエストをルーティングし、複数のサービスにリクエストを分散させ、追加のセキュリティと認証を提供することで、クライアントのリバースプロキシとして機能します。
APIゲートウェイを実装するために使用できる技術は、API管理プラットフォームを含めて複数ありますが、マイクロサービスアーキテクチャがコンテナやKubernetesを使って実装可能です。ゲートウェイは通常Ingressか、最近ではIstioを使って実装されます。
マイクロサービス のメリット
コスト削減と効率向上
マイクロサービス は一般的にモノリシックなアプリケーションよりもシンプルで効率的であるため、全体的なコスト削減につながります。さらに、マイクロサービス は自己完結型であるため、モノリシック・アプリケーションで必要とされるようなレベルの調整やコミュニケーションは必要ありません。組織が目の前のタスクに適したテクノロジーを使用できるようにすることで、マイクロサービスは効率を向上させ、エラーの数を減らせます。例えば、マイクロサービス ごとに異なるテクノロジー・スタックを選択することで、パフォーマンスとスケーラビリティを向上できます。
敏捷性と拡張性の向上
マイクロサービスは、非常に簡単に水平方向に拡張することができるため、拡張性が必要な状況に最適です。さらに、マイクロサービスは小さくモジュール化されているため、従来のモノリシックなアプリケーションよりもはるかに迅速にデプロイできます。この俊敏性の向上は、市場の変化に素早く対応する必要がある組織にとって大きな利点となるでしょう。
メンテナンスとアップデートが容易
マイクロサービスは小規模で自己完結型なので、モノリシックなアプリケーションを更新するよりもはるかに簡単に更新できます。さらに、各マイクロサービスが特定のタスクを担当するため、更新時にエラーが発生する可能性が低くなります。そのため、メンテナンスやアップデートのリスクや時間が大幅に削減可能です。
市場投入までの時間を短縮
マイクロサービスは、企業が製品をより早く市場に投入するのにも役立ちます。アプリケーションをより小さく管理しやすい断片に分割することで、機能ごとに開発しリリースできます。モノリシックなアプローチを使った場合よりも、製品をより早く市場に投入できることが多いです。
独立展開
マイクロサービスは独立してデプロイ可能であるため、組織はアプリケーションをよりコントロールしやすくなります。このコントロールの向上は、市場の変化に素早く対応する必要がある組織にとっては大きな利点となります。さらに、マイクロサービスを使用することで、組織はモノリシックなアプリケーションが大きくなりすぎて扱いにくくなったときに起こりうる「モノリシック・ブルー」を避けることができるでしょう。
マイクロサービス のデメリット
高い複雑性
マイクロサービスには多くの利点がありますが、同時に複雑さも伴います。この複雑さは、マイクロサービスの扱いに慣れていない組織にとって大きな課題となり得ます。さらに、マイクロサービスは非常に独立しているため、エラーを追跡して解決するのが難しい場合があるでしょう。
ネットワークトラフィックの増加
マイクロサービスは自己完結型に設計されているため、互いに通信するためにネットワークに大きく依存します。その結果、レスポンスタイムが遅くなり（ネットワークレイテンシー）、ネットワークトラフィックが増加する可能性があります。さらに、複数のマイクロサービスが互いに通信しているときに発生するエラーを追跡するのが難しくなるでしょう。
コードの再利用の制限
マイクロサービスは一般的に複数のプログラミング言語で記述され、異なるテクノロジースタックを使用するため、コードの再利用にも限界があります開発時間とコストの増加につながるため、マイクロサービス間でコードを共有することは困難です。
DevOpsへの依存
マイクロサービスで成功するためには、組織は強力なDevOpsチームを持つ必要がああります。DevOpsがマイクロサービスのデプロイと管理を担当するためです。優れたDevOpsチームでなければ、マイクロサービスベースのアプリケーションの実装と管理を成功させることは難しいでしょう。
グローバルなテストとデバッグの難しさ
マイクロサービスベースのアプリケーションのテストとデバッグは、アプリケーションが複数のサーバーやデバイスに分散しているため、困難な場合があります。アプリケーションを効果的にテスト・デバッグするためには、システムの一部であるすべてのサーバーやデバイスにアクセスできる必要があります。そのため、大規模な分散システムでは困難です。
マイクロサービス の導入は慎重に検討しよう
お察しの通り、モノリシックなアーキテクチャからマイクロサービスへの移行は、誰にでもできる仕事ではありません。多くの重要な検討を行い、いくつかの長所と短所を比較検討する必要がある場合は、信頼できるパートナーからの専門的な支援が必要です。
Relipaでは、超複雑なモノリシック・アプリケーション・アーキテクチャであっても、マイクロサービスを実現します。私たちは、あなたがシフトする際に遭遇するかもしれない多くの不都合を緩和することができます。
マイクロサービス の向いているケース
マイクロサービスの向いているケースを4つ上げるとすれば、以下のようなものが考えられます。
- 規模が大きく、機能が多岐にわたるシステム
マイクロサービスでは、機能を細分化して開発・運用できるため、モノリシックなシステムよりも変更や拡張が容易です。
- ビジネス要件や市場環境が頻繁に変化するシステム
マイクロサービスでは、個々のサービスを独立してデプロイできるため、素早く新機能や改善をリリースできます。
- 異なる技術やチームを活用したいシステム
マイクロサービスでは、各サービスに最適な技術や開発言語を選択できるため、技術的な自由度が高くなります。また、小規模なチームで開発できるため、コミュニケーションや進捗管理もしやすいです。
- 負荷分散や可用性を重視したいシステム
マイクロサービスでは、各サービスに応じて負荷を分散できるため、パフォーマンスやコスト効率が向上します。また、障害が発生しても他のサービスに影響を与えにくいため、可用性も高くなります。
実際の マイクロサービス の使用例
アマゾン
多くの新興企業と同様に、Amazon はモノリシック アーキテクチャでアプリを作成して起動するのが簡単であるため、モノリスとして構築されました。しかし、同社は急速に成長し始めたため、多くの新機能を開発し、オンライン プラットフォームを迅速に拡張する必要がありました。
これにより、非常に高度に分離されたアーキテクチャを作成することができました。
ロブ・ブリガム
AWS 開発者ツール製品
責任者
Amazon のコードベースは 2001 年に非常に大きく複雑になりました。同社は何百人ものソフトウェア エンジニアがリリースしたすべての変更を実装する必要がありました。開発者は、すべての競合を解決し、すべての変更を 1 つのバージョンにマージするのに多くの時間を費やす必要がありました。
さらに、コードベースを再構築し、製品の新しいバージョンが正しく動作することを確認するために多くのテストを実行する必要がありました。その結果、製品の納品スケジュールが許容できないものになってしまいました。パイプラインの簡素化を目指して、同社のソフトウェア エンジニアは革新的なアイデアを開発しました。彼らはモノリスを分解することに決めました。
彼らはコードベースを徹底的に分析し、唯一の目的を果たす機能ユニットを割り当てました。開発者はアイテムを取り出して独立したマイクロサービスを作成し、API 統合を使用してそれらを接続しました。
その後、すべての製品開発プロセスを徹底的に分析しました。Amazon のエンジニアは、CI/CD パイプラインのアイドル時間を排除する自動化ソリューションの開発を開始しました。
Netflix
Netflix は、マイクロサービス 導入の最も若いビジネス ケースです。同社が立ち上げた最初の Web アプリはモノリスでした。このサービスは人気を博し、急速に成長し始めました。
Netflix は、AWS で堅牢なマイクロサービス アーキテクチャを構築し、進化させてきました。
当社のマイクロサービス アーキテクチャは、エンジニアリング チームを互いに切り離し、必要なだけサービスを構築、テスト、デプロイできるようにします。
Netflixテクノロジー ブログ
したがって、同社は顧客から提出されたすべてのリクエストを処理する上で多くの課題に直面しています。これにより、多くのデータベース障害が発生しました。
同社は、オンプレミスのデータベースをアマゾン ウェブ サービスのクラウドベースのソリューションに置き換えることを決定しました。クラウド サーバーは、すべてのリクエストを処理するために必要な量のリソースを取得するために、水平方向に簡単に拡張できます。
開発者は、データベースをクラウドに移行するためにモノリス アーキテクチャを分離する必要がありました。同社は、分離されたアーキテクチャを使用することによるプラスの効果に気づいてから、2 年をかけてモノリシック アーキテクチャからマイクロサービスに切り替えました。
ウーバー
Uber は、すべてのプロセスを処理する 1 つのコードベースを備えたモノリスとして開始されました。モノリシック アーキテクチャには、ドライバーと乗客の接続、支払いの処理、旅行の管理などに必要なすべての機能が含まれています。
同社が高いペースで成長し始めたとき、サービスを迅速に拡張する際に多くの課題に直面しました。モノリシック アーキテクチャでは、開発者はコードベースを再デプロイして新しい変更を実装する必要がありました。たとえ小さな変更であってもコードベース全体に影響を与えるため、新機能をリリースするには包括的なテストを実施する必要がありました。
同社は、新機能のたびに消費される開発者リソースと時間の数に満足できず、アプリケーションをいくつかのマイクロサービスに分割することにしました。
その結果、マイクロサービス アーキテクチャを採用しました。
最終的に、私たちのシステムはより柔軟になり、チームがより自律的になれるようになりました。
ウーバーウー
バーテクノロジーズ株式会社
採用されたソリューションは、同社が請求、旅行管理、ドライバー管理、通知などのさまざまなサービスを個別にスケールアップするのに役立ちました。開発者はマイナーアップデートをリリースするためにコードベース全体を調べて更新する必要はありません。
マイクロサービスの向いていないケース
マイクロサービスの向いていないケースを3つ上げるとすれば、以下のようなものが考えられます。
- 規模が小さく、機能が単純なシステム
マイクロサービスでは、設計や管理にかかるコストや複雑さが増加するため、システム全体として見た場合にメリットが少なくなります。
- ビジネス要件や市場環境が安定しているシステム
マイクロサービスでは、変更や拡張に対応しやすい反面、データの一貫性やセキュリティなどに注意を払う必要があります。疎結合でサービスが独立しているため、個々に新しい機能を追加しやすいです。変化が少ない場合は、モノリシックなシステムで十分に対応できる可能性があります。
- 同じ技術やチームで開発したいシステム
マイクロサービスでは、各サービスに最適な技術や開発言語を選択できるメリットがありますが、それは同時に技術的な多様性や学習コストを増加させることでもあります。また、小規模なチームで開発することが推奨されるため、組織的な変更も必要になる場合があります。
まとめ
結論として、マイクロサービス・アーキテクチャは、従来のモノリシック・アーキテクチャ比べて多くの利点があります。
利点は3つあり、下記のとおりです。
- より高速なパフォーマンス
- より容易なスケーラビリティ
- より容易なコードの再利用
などが含まれます。
しかし、マイクロサービス・アーキテクチャには、より複雑な開発とデプロイ、高い実装コストなど、多くのデメリットもあります。そのため、マイクロサービスが組織にとって適切なソリューションであるかどうかを決定する前に、マイクロサービスの長所と短所を比較検討することが重要です。
Web ・アプリケーション・システムの開発における 7 年間以上の経験を持つ Relipaは、市場での地位を徐々に確立してきました。 Relipa の専門スタッフは、Web プログラミング言語に堪能なだけでなく、最新のフレームワークの適用にも柔軟に対応できます。 私たちは、設計から実装まで、保証された品質と迅速なプロジェクト完了時間で、すべてのお客様の要件を満たすことに尽力しています。
