マイクロサービス アーキテクチャによるアプリケーション設計

マイクロサービスを導入する十分な理由があるとはいえ、移行はそう簡単ではありません。マイクロサービスアーキテクチャの実装を成功に導くには、組織全体（ビジネスチーム、開発、ITサポート、セキュリティ）が歩調を合わせ、業務を最適化する準備を整える必要があります。

アプリケーションの設計をするにせよ、既存のアプリケーションに機能を追加するにせよ、あるいは、レガシー・アプリケーションをモダンナイゼーションするにせよ、マイクロサービが実際に必要かどうかを最初に見極めることが重要です。マイクロサービスアーキテクチャ実装の経験豊かなコンサルタントとして、これがいかに複雑な問題であるかを当社は理解しています。当社のチームは、お客様と協力してマイクロサービスがふさわしいかどうかを見極め、確立されたベストプラクティスによってお客様がマイクロサービスアーキテクチャを導入できるようサポートします。

当社は、システム全体を壊してビジネスを中断させることなく、お客様のアプリケーションを段階的に小さなコンポーネントの集合に再編成していく、段階的な変換を推奨しています。

各マイクロサービスは、異なるビジネス機能を担います。そのため、最初のステップは、自己完結型ユニットとしてグループ化できる機能セットを特定することです。複雑なレガシー・アプリケーションには、単独で独立して機能し、他のシステムと独立して展開できるマイクロサービスに変換できるモジュールが数多くあります。

当社として、抽出のためのモジュールを特定し、優先順位付けをしていきます。最もビジネスクリティカルでないモジュール、抽出が容易なモジュール、最も有益なモジュール、または特定のリソース要件を持つモジュールは、早期の段階で適切な機能を追加することができます。モジュールがマイクロサービスに変換されるごとに、モノリスを縮小し、最終的にはマイクロサービスにすることができます。

マイクロサービスは、DevOpsと併用することで一層、機敏性と効率性を向上させることができます。evOpsチームは独立したモジュールに並列で取り組むことができ、これにより開発が加速します。マイクロサービスの数が増えるにつれて、自動化された継続的な統合とデリバリーパイプラインが手動エラーを減らしつつ、段階的なリリースを可能にします。CI/CDパイプラインに統合された継続的なテストは、製品の品質向上を実現します。

マイクロサービスの独立した性質は、DevOpsチームが短時間でより多くを達成するのに役立ちます。これらのアプローチを組み合わせることで、革新を促進し、より大きなビジネス価値を生み出すことが可能となります。

コンテナは、マイクロサービスアーキテクチャに理想的であり、開発からテスト、最終的な展開まで一貫した環境を提供します。各マイクロサービスに仮想マシンを使用すると、膨大なオーバーヘッドが発生し、単一の仮想マシンに複数のマイクロサービスを展開するとサービス間での競合が発生する可能性があります。複数のコンテナが単一のオペレーティングシステムでサポートされるため、マイクロサービスアーキテクチャでは仮想マシンよりもコンテナの使用がはるかに効率的です。

性能の観点からも、コンテナ化は有利です。コンテナは軽量で素早く起動し、マイクロサービスベースのアプリケーションの変動するワークロードにより適しています。細かい実行環境、単一のオペレーティングシステムに複数のコンポーネントを収容できる能力、不規則な作業負荷にも臨機応変に対応できることから、マイクロサービス用にコンテナが優先的に選ばれることが多くなっています。

コンテナ化したマイクロサービスのデプロイを自動化し、さまざまなマイクロサービスをすべて簡単に管理できるよう、当社では、Kubernetesといったコンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェアのセットアップも実施しております。

数千ものマイクロサービスを監視することは、モノリシックなシステムと比較して手間がかかります。モノリシックなシステムでは1か所だけを見ればよいのに対し、多くのマイクロコンポーネントを視認し、簡単にデバッグするためには、集中化されたログとダッシュボードが必要です。

コンテナ化したマイクロサービスを監視するオープンツールは数多くあります。当社では、FluentdやLogstashといったツールを活用して、各マイクロサービスからのログを集め、中央データベースに格納しています。データベースが、将来のクエリ用にデータのインデックスを作成し、データを保存します。Kibanaなどのツールを使用して、ログ分析から得られた洞察を示す視覚的なダッシュボードを作成することも可能です。

マイクロサービスにおける共通課題がサービス間の通信です。マイクロサービスは他のマイクロサービスを直接呼び出さず、メッセージブローカーまたはAPIゲートウェイ経由で呼び出します。また、マイクロサービスは、さまざまなバックグラウンド処理によってデータのインポート／エクスポートを行うこともできます。

ユーザーがある操作を行うのに、複数のマイクロサービスが遠隔呼び出しを通したネットワークで互いにやり取りする必要がある場合、ネットワークが利用できなかったり、やり取りに1つでも大幅な待ち時間が発生したりすれば、アプリケーション全体に次々と不具合が及ぶ可能性があります。サーキットブレーカーパターンを使用すれば、重要なサービスのダウンタイムや待ち時間を高度に処理することが可能になります。この方法は、やり取りの負荷を軽減することで、応答しないサービスを回復します。サーキットブレーカーは、不応答数が一定の閾値に達すると、不応答サービスへの呼び出しを行わずにエラーを返します。このサービスへの接続は、定期的なチェックで問題がない場合にのみ回復され、問題がある場合は、回線はオープンのままです。

マイクロサービスの数が増えるにつれ、サービス間通信の処理もより一層困難になっていきます。サービスディスカバリー、負荷バランシング、サーキットブレーキング、認証や個々のマイクロサービスに必要なその他の機能は、すべてのサービスに共通の別のレイヤーにまとめて抽出できます。サービス間通信を処理するためのこういったインフラレイヤーが、サービスメッシュと呼ばれるものです。

サービスメッシュに大多数のネットワークをオフロードすることで、開発者は、ビジネスロジックに集中して取り組めます。どのような言語で書かれたマイクロサービスでも、言語に依存しないサービスメッシュとの連携が可能です。サービスメッシュのオープンソースソフトウェアには、IstioやLinkerd、Conduitがあり、Kubernetes環境にはConduitが最適とされています。

マイクロサービス環境のセキュリティは、モノリシックシステムとは異なる手法で実施する必要があります。ネットワークで行われるサービス間通信は、システムをハッキングする機会を第三者に与えかねません。当社のアーキテクトはセキュリティの専門家と連携し、マイクロサービスの分散環境に構築されたアプリケーションを保護するのにふさわしいツールを使用します。

アイデンティティ／アクセス管理

当社では、カスタムの認可プロトコルを設計できますが、すでに使用できるよう組み込まれたOAuthベースの認可サービスといった、業界標準もあります。

ゼロトラストモデル

各マイクロサービスの認証および認可は、個別に行えます。このような「信頼することなく、常に確認する」というやり方によって、より厳重なセキュリティが可能になります。

数段構えの守り

機密情報を扱うサービスに多層セキュリティレイヤーによる対策を講じることで、攻撃者がサービスに侵入しにくくなります。

DevSecOps

セキュリティユニットテストを組み込んでCI／CDサイクルにセキュリティを統合すること、また、ロールベースのアクセス制御方法やコンテナ堅牢化対策を行うことで、アプリケーションのセキュリティが向上します。