マイクロサービスを採用する際に念頭に置くべき 4 つの問題点

2019-04-03 (Wed)  •  By 伊藤  •  活用のヒント  •  マイクロサービス 翻訳

今回の記事は、ゴーツーグループ ブログ (英語版)「Modernizing to Microservices? Keep These Challenges in Mind! 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

マイクロサービスが提唱されたのはしばらく前ですが、社内のエンタープライズ IT システムの現代化を模索している組織にソフトウェア アーキテクチャの基盤として人気が出てきたのは最近のことです。

基本的にマイクロサービスはアーキテクチャのスタイルです。アプリケーションは小規模、独立型、かつドメイン固有なサービスの集合として構成されており、それぞれのサービスはそれ単独で配置およびテスト可能です。また、主な価値提案は、ソフトウェアを市場により迅速に出荷できることです。チームがこれら独立したアプリケーション コンポーネントで作業することにより、不具合修正と新しい能追加の両方をスピードアップできます。

マイクロサービスの利点は明確ですが、その実装に関する問題点はあまり言及されてきませんでした。今回のブログ投稿では、マイクロサービスが引き起こす可能性がある面倒な問題点に着目します。

1. 分散されたトランザクションが複雑さを増大する

モノリシック アプリケーションの場合、単一かつ共有のデータベース サーバーで構成されているためトランザクション管理はより単純です。トランザクションはデータベース レベルで開始され、トランザクションの最終結果により、コミットされたり、ロールバックされたりします。しかし、マイクロサービスの場合、各サービスはシステム毎に独自のデータベースを持っています。これはトランザクションをコミットするプロセスがとても複雑になることを表しています。

電子商取引アプリケーションについて考えてみましょう。まず、顧客からの注文を受けます。次に、在庫ならびにクレジット カードが利用可能であるかを確認します。そして発送を行います。分散シナリオの場合、ユーザー処理サービスや支払いゲートウェイ サービスなど、アーキテクチャは数多くの小さなサービスに分割されます。そして、それぞれが独自のデータベースを持っています。アプリケーションはローカル ACID トランザクションを使用できません。 その理由は、複数のデータベースを横断して ACID 特性を管理する直接的かつ単純な方法は存在しないからです。マイクロサービスにおいてトランザクション管理が問題となるのはこのためです。

2. マイクロサービスの検証は複雑である

マイクロサービスをベースとしたアプリケーションの検証は簡単ではありません。マイクロサービスを個別に検証することに加え、API の検証が必要です。すべてのマイクロサービスがお互いにシームレスに確実に通信することを確認する必要があります。アプリケーションを構成する多くのサービスが、これらサービス間の依存性に加え、検証プロセスにおける複雑さの原因となる可能性があります。例えば、効果的な統合テストを作成するためには、テスト担当者は各種サービスごとに複数のログを注意深く分析する必要があります。複数の独立したチームが分散した機能上で同時に作業している場合、ソフトウェア全体の集中的な検証ならびに総合的な品質保証の調整のための理想的な時間枠を決めることがとても困難になります。

3. 運用上の問題が増加する

運用チームは単一のアプリケーションではなく、サービス全体のエコシステムを管理する必要があります。即座にサーバーをプロビジョニングできることが重要な前提条件となります。リソースをプロビジョニングするために数日や数か月もかかる場合、マイクロサービスを最大限に活用するために必要なペースを保持できません。また、インフラストラクチャのプロビジョニングならびに停止を自動的に行う必要があります。その理由は、これらサービスはスケール アップ/ダウンすることがあるためです。それに加え、プロビジョニング能力は、単一のシニア Dev/DevOps 担当者だけでなく、より大規模なチーム内で配分される必要があります。

それ以外にも、システム ダウンタイム、サービス遅延、そして予期しない応答など、複数の障害に関する問題への対応にも準備しておくべきです。また、負荷分散戦略が必要となることが予想されます。これはモノリシック アプリケーションの場合よりもはるかに複雑です。

しかも、管理するサービスが多い場合、それぞれのサービスが自身の言語、プラットフォーム、ならびに API を持っています。検証環境で発見されなかった多くの問題が発生する可能性があります。したがって、インフラストラクチャ全体の管理と深刻な問題をすばやく検出するための強力な監視機能を確保することが重要になります。

4. 文化的な心構えが不足している

各サービスを個別に開発/検証/配置/管理するために、マイクロサービス アプローチでは自己充足かつ自主的なチームが必要となります。このアプローチの原則の 1 つとして、組織されたチームはアマゾンが言うところの「ピザ 2 枚ルール 」に従うことが挙げられます。つまり、夕食に 2 枚のピザで足りる程度のより小規模な部門連係チームです (10 人以下)。各チームは、開発、テスト、運用、データベース管理、UX、ならびに場合によっては製品管理の専門家でバランスよく構成されているべきです。

チームの個人の効率性を予言する一方で、大規模な組織でうはある種の問題を引き起こすかもしれません。チームは他チームが取り組んでいることに関する可視性を失うかもしれません。各サービスは機能と目的が不明なブラックボックスになります。これはシステム全体の理解を妨げることになります。結果として、作業の重複や複雑さの追加につながります。責任が明確に定義されていない場合、非難合戦や責任のなすり合いになる可能性があります。

結論

アプリケーションの開発トレンドは進化し続けています。マイクロサービスを活用するか、従来のモノリシック アーキテクチャを利用するかの議論はより激しくなるでしょう。あなたがマイクロサービスを求めている場合、あなたが戦略を立てる際に一歩離れてこれら複雑さをすべて熟考する価値はあります。問題点を理解する良い方法は、展開しやすい小規模なサービスから開始することです。より早く結果を出すことができ、かつ初期の経験を得られます。これにより、特定のアプリケーションと環境に関連するトレードオフの追跡と評価を行えます。また、これら初期の経験を得ることで、マイクロサービスへのさらなる投資がより合理的になります。


Related Articles

お気軽にお問い合わせください

お問い合わせ