幾つ実践してる？ マイクロサービスの開発効率と保守性を最大限に高める「ベストプラクティス8選」：ドメイン駆動設計の統合からAPIのセキュリティ確保まで

TechTargetは「マイクロサービスのベストプラクティス」に関する記事を公開した。分散型サービスのデプロイで生じる複雑さ、遅延、セキュリティの問題を軽減し、強固かつスケーラブルなアプリケーション構築に役立つ幅広いベストプラクティスを探る。

[Tom Nolle，TechTarget]

　TechTargetは2024年10月25日（米国時間）、「マイクロサービスのベストプラクティス」に関する記事を公開した。

覚えておきたいマイクロサービスのベストプラクティス8選（提供：TechTarget）

　マイクロサービスはアプリケーションを小規模なサービスに分割し、ドキュメント化されたAPIで接続することで、開発の効率性と保守性を最大化する。しかし、その効果を十分に発揮させるには、設計プロセスを適切に構築する必要がある。

　マイクロサービスのベストプラクティスに従えば、マイクロサービスアーキテクチャの強みをうまく生かして、分散型サービスのデプロイメントによって生じる可能性のある複雑さ、遅延、セキュリティの問題を軽減できるだろう。

　本稿で紹介するのは以下の8つだ。

• 上流設計を優先する
• コンテキストを無視しない
• 分解しすぎない
• マイクロサービスをコンテナでホストする
• 公開したAPIのセキュリティを確保する
• データベース戦略を慎重に選択する
• 非同期APIによって回復力と拡張性をサポートする
• GitOpsとDevOpsをパイプラインに統合する

1．上流設計を優先する

　マイクロサービスを効果的に実装するには、ドメイン駆動型設計（DDD：Domain-Ddriven Design）を取り入れる。つまり、アプリケーションのさまざまな機能要素をビジネスドメインや技術ドメインに沿って設計する。例えば、アプリケーションを入力、処理、出力の組み合わせと考えれば、各ドメインを機能単位またはマイクロサービスに分解できる。分解する過程で、各マイクロサービスの機能とそれぞれが呼び出されるときに交換するデータを定義する。

　新たなマイクロサービスをアプリケーションに追加する際には、既存の定義済みサービスがその機能を論理的に対応可能かどうかをまずは確認するべきだ。

2．コンテキストを無視しない

　ステートフルな操作では、操作が行われるコンテキストに応じて出力が異なる。例えば、銀行口座からの引き出しのような処理（トランザクション）では、口座の状態（この場合は残高）に応じて異なる結果を出力する必要がある。一方で、情報の編集や検証など、ステートレスにできる機能は多い。ステートレス機能をサポートするマイクロサービスはコンテキストデータを保持する必要がなく、コピーであってもその処理要求を満たすことができる。

　ステート情報を必要とするマイクロサービスは、API呼び出しやデータベース要求などの方法を通じて、情報のソースから取得する必要がある。各ドメインやマイクロサービスのステート要件を理解し、それを適切に管理することは、強固でスケーラブルなマイクロサービスアプリケーションの開発において極めて重要だ。

　APIとデータオブジェクトを変更不可にするという概念に精通する開発者は、ここでその原則が役立つと感じるだろう。

このドメイン駆動設計の例では、アプリケーションの機能サブドメインが対応するマイクロサービスとペアになっている

3．分解しすぎない

　「単一責任の原則」（Single Responsibility Principle）は、個々のマイクロサービスが、理想的には最小かつ完全な機能セットを網羅すべきであるとする考え方だ。例えば、論理ステップ1からステップ3が常に一緒に同じ順序で呼び出されるのであれば、それらのステップを1つのマイクロサービスに含める。それ以上に機能単位を細分化しても、開発や運用にメリットが追加されることはなく、オーバーヘッドや遅延が増加する可能性がある。

　過剰な分解はアプリケーションロジックの理解を難しくするだけでなく、デプロイやオーケストレーションをより複雑にする可能性がある。全体的な遅延がエクスペリエンス品質の要件（Quality of Experience）を満たすようにするには、マイクロサービスアプリケーションのワークフローをマッピングすることが役に立つ。

4．マイクロサービスをコンテナでホストする

　コンテナホスティングは、マイクロサービスのデプロイや再デプロイを容易にする。特に、Kubernetesのようなコンテナオーケストレーターを使用する場合に効果的だ。コンテナは移植可能で、構成がパラメーター化され、オーケストレーションツールによってライブラリとデータベースの要件を確実に満たすことができる。

　コンテナは仮想マシンよりもサーバリソースの消費が少なく、クラウド環境でのホスティングコストが抑えられるという特徴もある。コンテナを使うことでAPI接続を最適化し、レイテンシ（遅延）を減らすこともできる。

5．公開したAPIのセキュリティを確保する

　コンテナベースのマイクロサービスデプロイではほとんどの場合、アプリケーション内で利用可能なプライベートIPアドレスがAPIに割り当てられる。だが、より広範なAPIへのアクセスが必要な場合や、複数のアプリケーションでマイクロサービスを使用する場合は、自社のVPN（Virtual Private Network）またはインターネットのパブリックアドレス空間へのAPIの公開が必要になることがある。

　公開されたAPIは攻撃に対して脆弱（ぜいじゃく）になるため、セキュリティを強化する具体的な対策が必要となる。これには、設計方針にも影響を及ぼす可能性がある。公開されたAPIおよびそのデータへのアクセスを保護するために暗号化を利用し、セキュリティ侵入テスト（ペネトレーションテスト）を開発プロセスに組み込むことが推奨される。

　さらに、公開範囲を制限するには、アプリケーションをグループに分割し、マイクロサービスの共有をそのグループ内に限定した後、グループをクラスタに分けるか、各グループが独自のプライベートIPアドレス空間を持つように構造化するのが有効だ。また、ファイアウォールを利用してグループ間のアクセスを防止することも効果的だろう。

6．データベース戦略を慎重に選択する

　適切に構成されていないデータベースは、マイクロサービスアプリケーションにおいて単一のスレッド要素（つまりボトルネック）となり、並列性やスケーラビリティに悪影響を与える可能性がある。こうした問題を解決するにはサービスごとにデータベースを割り当てるとよいが、アプリケーションをクラウドにデプロイすると、データストレージのコストが増加する可能性がある。

　一般的には、マイクロサービスごとに状態情報のデータベースストレージをデプロイする必要がある。だが、複数のマイクロサービスからアクセス（または更新）されるデータベースを用意することもできる。その場合、更新が正しく反映されるように特別なマルチフェーズのコミット手順が必要になる可能性がある。更新のためのロックが必要な場合は、アプリケーションのパフォーマンスへの影響を評価し、全体設計を見直して悪影響を最小限に抑えることを検討すべきだ。

サービスごとにデータベースを用意するアプローチでは、各分散型サービスに専用のデータベースを割り当てることで、疎結合と独立したスケーリングを実現しやすくなる。

7．非同期APIによって回復力と拡張性をサポートする

　同期モデルでは、API呼び出しは、呼び出した関数から結果を受け取るまでタスクの実行を中断する。この動作は、スケーリング、負荷分散、再デプロイを妨げる可能性がある。そのため、非同期APIは、マイクロサービスアプリケーションやpub/sub（パブリッシュ／サブスクライブ型）メッセージングやサービスメッシュといった本質的に非同期の作業やイベント分散設計パターンにとって、より優れた選択肢となる。

　非同期APIでは、実行を一時停止しているマイクロサービスを認識するために、コンテキストや状態を制御するコード対応が必要になる。非同期APIの使用をサポートする際には、一貫性によってメンテナンスが容易になるため、単一の戦略とツールを選択するよう努めることが重要だ。

8．GitOpsとDevOpsをパイプラインに統合する

　マイクロサービスの保守性の利点を最大化するため、開発者はデプロイを開発パイプラインに組み込み、開発とデプロイメントをマイクロサービスコンポーネントと効果的に連携させるように最適化することが重要だ。これを実現する最も簡単な方法は、CI/CD（継続的インテグレーション／継続的デリバリー）や迅速なデプロイを可能にするプラクティスとツールを採用することだ。

　マイクロサービス環境ではバージョン管理が非常に重要になる。API構造やコンテンツ定義が変更された場合、複数のマイクロサービス間で調整が必要になることがあるからだ。特に、アプリケーションがマイクロサービスを共有している場合、変更に関連する全ての依存関係が明確でない場合がある。このようなアプリケーション間の依存関係は、非マイクロサービスの開発ではあまり問題にならないため、見落とされることがある。

　ただし、アプリケーションがマイクロサービスを共有している場合、ドリフト（drift）が発生する可能性もある。ドリフトは、本来同じであるべきマイクロサービスの複数バージョンを生み出し、それぞれが特定のアプリケーションに依存してしまうことになる。