ポイント: マイクロサービスアーキテクチャを構築するためのベストプラクティスは、サービスの独立した開発とデプロイを促進することによってアプリケーション管理を強化します。主要な戦略には、マイクロサービスを個別にデプロイすること、柔軟性のためにコンテナ化すること、デプロイメントプロセスのための自動化ツールを利用することが含まれます。
- マイクロサービスは緩やかに結合され、高い結束性を持つように設計されるべきです。
- より良いエラーハンドリングのために中央集中型のログ記録および監視システムを実装します。
マイクロサービスは、アプリケーションを小さく、自律的で、緩やかに結合されたサービスのコレクションとして設計・開発する進化したアーキテクチャパターンです。その基本的なレベルでは、各個別のマイクロサービスはアプリケーションとして機能します。アプリケーションをマイクロサービスのコレクションとして構成することで、以下が促進されます：
- 容易で迅速なデプロイ
- スケーラビリティ
- 保守性
これにより、アプリケーション全体の管理と保守が大幅に容易になります。
典型的なマイクロサービスフレームワーク
これらの利点は、大規模および小規模の両方のDevOps組織によるマイクロサービスの広範な採用を裏付けています。これらの利点のおかげで、マイクロサービスの採用は引き続き増加することが期待されますが、利益を最大化するためには、回復力のある分散システムを運用するためのベストプラクティスを採用することが重要です。ここでは、マイクロサービスの成功に不可欠な15のベストプラクティスを見ていきましょう。
マイクロサービスアーキテクチャのベストプラクティス
この記事では、次のプロジェクトのためにマイクロサービスを考え始める時点から、アプリケーションのデプロイメントの終わりまで、さまざまなソフトウェア開発ライフサイクル（SDLC）フェーズを反映するカテゴリに、これらのベストプラクティスをグループ化します。これらのヒントには、新しい採用者特有のプラクティスも含まれているため、モノリシックからマイクロサービスフレームワークに成功裏に移行できます。
計画と組織のために…
- マイクロサービスアーキテクチャが要件に基づいて適しているかどうかを判断します。大手企業が行っているからといって、マイクロサービスアーキテクチャを採用しないでください。要件を分析して、価値を提供する機能にセグメントできる場所を確認する必要があります。アプリケーションがコア機能と操作性を保ちながらマイクロサービスに細分化できることを確認するために、十分な調査を行ってください。
- アイデアにみんなを賛成させます。モノリシックアーキテクチャからマイクロサービスへの移行は、最初は長くて面倒なプロセスであり、その影響は開発チームに限られません。ステークホルダーは、採用しなければならないインフラの変更に必要な時間、費用、および技術的専門知識を考慮する必要があります。エンジニアリングチームは、移行の間、実施者およびユーザーとしてかなりの混乱に直面します。
- マイクロサービスを中心にチームを構築します。各マイクロサービスはそれ自体が独立したアプリケーションとして機能するため、チームもそうであるべきです。異なるマイクロサービスを扱うために別々のチームを形成します。これには、特定のサービスを自立して開発、デプロイ、および管理するために必要なスキルとツールを持つ必要があります。チームは多才であり、コミュニケーションに無駄な時間をかけることなく、自律的に業務を処理できるだけの規模が必要です。
マイクロサービスを設計する際に…
- マイクロサービスをビジネス機能やサービスと区別します。これにより、大きすぎるか小さすぎるマイクロサービスを構築するのを避けることができます。前者の場合、マイクロサービスアーキテクチャを使用しても利益が得られません。後者の場合、運用コストが指数関数的に増加し、得られる利益を上回る結果になります。
- サービスを緩やかに結合し、高い結束性を持ち、単一の境界コンテキストをカバーするように設計します。緩やかに結合されたサービスは、他のサービスに最小限依存します。高い結束性を持つには、サービスの設計が単一責任原則に従うことが必要です。つまり、1つの主要な機能を実行し、それをうまく行うべきです。最後に、サービスがドメイン特有であり、ドメインの内部詳細とドメイン特有のモデルを含むように設計します。これにより、マイクロサービスは単一の境界コンテキストをカバーし、ドメイン駆動設計（DDD）を実現します。
- サービス間の通信にはAPIとイベントを使用します。サービスは互いに直接呼び出すべきではありません。代わりに、認証、リクエスト、応答、サービスのスロットリングを処理するAPIゲートウェイを設計します。APIゲートウェイを設置することで、サービスに変更がある場合には、APIゲートウェイから更新されたバージョンにトラフィックを簡単にリダイレクトできます。
- マイクロサービスアーキテクチャ内のセキュリティ脆弱性を考慮します。ベストプラクティスとして、セキュアなマイクロサービスフレームワークを確保するためにDevSecOpsモデルを採用します。重要なのは、マイクロサービスは一般的にその分散構造のために攻撃ベクトルに対してより脆弱であることです。そのため、セキュリティをプロビジョニングするには、モノリシックフレームワークと比較して完全に異なるアプローチが必要です。これがDevSecOpsが完璧な理由です。
マイクロサービスを開発する際に…
- 各サービスに対して別のバージョン管理戦略を持ちます。各サービスは、アクセスプロビジョニングを容易にしつつ、バージョン管理ログをクリーンに保つために独自のリポジトリを持つべきです。これは、他のサービスを破壊する可能性のある変更を実装する場合にも便利です。
- 開発環境は、マシン間で一貫性を保つべきです。サービスの開発環境を仮想マシンとして設定し、開発者がフレームワークに適応し、迅速に開始できるようにします。
- 公開しているサービスエンドポイントには後方互換性を含めます。呼び出し者を破壊したくありません。そのためには、破壊的変更を防ぐために厳格な契約テストを実装します。これにより、すべてのユーザーのクエリに対するAPI呼び出しに基づいた後方互換性が確保されます。これにより、組織は生産準備が整ったアプリケーションを迅速に構築できます。
データストレージと管理のために…
- 各マイクロサービスに対して異なるデータベースまたはデータストアを持ちます。マイクロサービスのニーズに合ったデータベースを選択し、含まれるデータに合わせてインフラとストレージをカスタマイズし、そのマイクロサービス専用に使用します。これは、各サービスが独立して維持され、他のサービスと協調して機能する堅牢なマイクロサービスフレームワークを実現するための重要な要素です。
サービスメッシュ対応のマイクロサービス
デプロイとホスティングのために…
- マイクロサービスを個別にデプロイします。こうすることで、定期的なメンテナンスやアップグレード作業中に複数のチームとの調整にかかる時間を節約できます。また、リソースを共有しているために、単一のサービスが他のサービスに影響を与えないようにする必要があります。各マイクロサービスをホストするために専用のインフラを使用することを強くお勧めします。こうすることで、各マイクロサービスが他のコンポーネントの障害から隔離され、フォールトトレランスが向上し、完全な停止を回避できます。
- マイクロサービスをコンテナ化します。 コンテナとマイクロサービスはしばしば一緒に使われます。コンテナ化されたマイクロサービスを使用することで、他のコンテナ上でホストされているサービスに影響を与えることなく、各サービスを独立してデプロイおよび管理できます。コンテナは、マイクロサービスアーキテクチャの目標に完全に一致するプラットフォーム非依存性と相互運用性を提供します。
- マイクロサービスのビルドを別にし、デプロイメントプロセスを自動化します。DevOpsモデルを実現するための重要な側面は、自動化を可能にすることで効率を向上させることです。Jenkinsのような自動化ツールを使用することで、継続的インテグレーションおよび継続的デリバリー（CI/CD）のワークフローを自動化できます。
メンテナンスと運用のために…
- 中央集中型のログ記録および監視システムを使用します。中央集中型のログシステムは、すべてのマイクロサービスが標準化された形式でログを送信することを保証しますが、各マイクロサービスのログは個別に保存されます。モノリシックモデルとは異なり、これにより迅速なエラーハンドリングと根本原因分析が助けられます。さらに、高度な監視ソリューションを使用することで、リソースの可用性を監視するだけでなく、侵害されたリソースを早期に特定することでセキュリティを維持できます。
マイクロサービスアーキテクチャの移行
マイクロサービスはアプリケーション管理を改善しますが、マイクロサービスアーキテクチャへの移行は複雑です。マイクロサービスを実装するアプローチは、ユースケースによって異なる場合がありますが、これらの基本的なベストプラクティスは普遍的です。常に、マイクロサービスの目標は、緩やかに結合され、分散され、独立したフレームワークを達成し、自動化と効率を可能にするDevOpsモデルを構成することです。
関連する読み物
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。