Share your requirements and we'll get back to you with how we can help.
マイクロサービスアーキテクチャ(MSA)は、アジリティ(Agility)の重要な要因として人気を集めています。NetflixやAmazonなどのおよび多くの他の大規模Webアプリケーションは、継続的なイノベーションのため、モノリシックな単位からマイクロサービスに移行しました。
現在、中小企業もこのモジュール型サービスを採用し、開発時間を大幅に削減し、より迅速に市場に参入しています。
急速なデジタル化と分散クラウドコンピューティングがマイクロサービスアーキテクチャを支持している一方で、これがすべてのケースでデフォルトのアプローチである必要はありません。重要な点は、やみくもに流行に追随するのではなく、必要性を見極めることです。当社は、しっかりと見極めを行い適切なアーキテクチャによる設計・構築を実現致します。
マイクロサービス アーキテクチャとは、さまざまなコンポーネントを作成し、分離した個別のサービスとして維持する、ソフトウェアの構築スタイルです。マイクロサービスはそれぞれ、1つのビジネス機能のみを担う小規模なもので、システムの残りの部分に影響を及ぼすことなく個別に導入することを意図しています。
従来、アプリケーションは、機能をすべて組み込んだ結合ユニットとして設計されていました。こういったソフトウェアは、通常、単一の装置にデプロイされ、垂直方向にしか拡張できません。これが実用的でないと認識されると、モノリシックな構造内の論理的なユニットが、ユーザーインターフェース、サーバーロジックまたはWebサービス、およびストレージのためのデータベースなど、物理的な層に分割されました(tiered architecture)
最終的に、Webサービスレイヤーがさまざまなサービスに垂直方法に分けられるサービス指向型アーキテクチャ(SOA)が、容易に拡張するための実行可能な設計となりました。マイクロサービスは、SOAの斬新的進化と捉えることができます。
以下に示すのは、マイクロサービスアーキテクチャによるリテールアプリケーションの例です。各サービスは、単一のビジネス機能のみを担います。その一方で、マイクロサービスは互いにコミュニケーションを取って必要な情報をやり取りします。
eコマースアプリケーションにおけるマイクロサービスアーキテクチャの例
規模の大小を問わず、企業は、顧客に関心を持ち続けてもらうため、顧客の高まる需要と期待に応え続けなければなりません。従来のソフトウェアの開発とデプロイの方法が頻繁に追いつけないことがある一方で、マイクロサービスのアプローチは、迅速に競争力を維持できるようにする特定のサービスを提供しています。
MSAは、異なる言語で書かれた分離したサービスを協調的に共存させることができます。企業は、各事業の能力にふさわしい技術スタックを自由に選択が可能
グローバルに分散するチームは、ソリューションが独立した小規模なフラグメントに分けられている場合、より生産的な作業が可能
それぞれのチームが別々のコンポーネントの作業を行えば、開発を加速でき、企業にビジネスの機敏性が加わることで、新たなコンポーネントの追加、デプロイ、拡張も個別に実装可能
不具合を隔離し、システム全体に影響を及ぼすことなくマイクロサービスを変更が可能となり、複雑なモノリシックシステムに比べ、アプリケーションのメンテナンスが容易
マイクロサービスを導入する十分な理由があるとはいえ、移行はそう簡単ではありません。マイクロサービスアーキテクチャの実装を成功に導くには、組織全体(ビジネスチーム、開発、ITサポート、セキュリティ)が歩調を合わせ、業務を最適化する準備を整える必要があります。
アプリケーションの設計をするにせよ、既存のアプリケーションに機能を追加するにせよ、あるいは、レガシー・アプリケーションをモダンナイゼーションするにせよ、マイクロサービが実際に必要かどうかを最初に見極めることが重要です。マイクロサービスアーキテクチャ実装の経験豊かなコンサルタントとして、これがいかに複雑な問題であるかを当社は理解しています。当社のチームは、お客様と協力してマイクロサービスがふさわしいかどうかを見極め、確立されたベストプラクティスによってお客様がマイクロサービスアーキテクチャを導入できるようサポートします。
当社は、システム全体を壊してビジネスを中断させることなく、お客様のアプリケーションを段階的に小さなコンポーネントの集合に再編成していく、段階的な変換を推奨しています。
各マイクロサービスは、異なるビジネス機能を担います。そのため、最初のステップは、自己完結型ユニットとしてグループ化できる機能セットを特定することです。複雑なレガシー・アプリケーションには、単独で独立して機能し、他のシステムと独立して展開できるマイクロサービスに変換できるモジュールが数多くあります。
当社として、抽出のためのモジュールを特定し、優先順位付けをしていきます。最もビジネスクリティカルでないモジュール、抽出が容易なモジュール、最も有益なモジュール、または特定のリソース要件を持つモジュールは、早期の段階で適切な機能を追加することができます。モジュールがマイクロサービスに変換されるごとに、モノリスを縮小し、最終的にはマイクロサービスにすることができます。
マイクロサービスは、DevOpsと併用することで一層、機敏性と効率性を向上させることができます。evOpsチームは独立したモジュールに並列で取り組むことができ、これにより開発が加速します。マイクロサービスの数が増えるにつれて、自動化された継続的な統合とデリバリーパイプラインが手動エラーを減らしつつ、段階的なリリースを可能にします。CI/CDパイプラインに統合された継続的なテストは、製品の品質向上を実現します。
マイクロサービスの独立した性質は、DevOpsチームが短時間でより多くを達成するのに役立ちます。これらのアプローチを組み合わせることで、革新を促進し、より大きなビジネス価値を生み出すことが可能となります。
コンテナは、マイクロサービスアーキテクチャに理想的であり、開発からテスト、最終的な展開まで一貫した環境を提供します。各マイクロサービスに仮想マシンを使用すると、膨大なオーバーヘッドが発生し、単一の仮想マシンに複数のマイクロサービスを展開するとサービス間での競合が発生する可能性があります。複数のコンテナが単一のオペレーティングシステムでサポートされるため、マイクロサービスアーキテクチャでは仮想マシンよりもコンテナの使用がはるかに効率的です。
性能の観点からも、コンテナ化は有利です。コンテナは軽量で素早く起動し、マイクロサービスベースのアプリケーションの変動するワークロードにより適しています。細かい実行環境、単一のオペレーティングシステムに複数のコンポーネントを収容できる能力、不規則な作業負荷にも臨機応変に対応できることから、マイクロサービス用にコンテナが優先的に選ばれることが多くなっています。
コンテナ化したマイクロサービスのデプロイを自動化し、さまざまなマイクロサービスをすべて簡単に管理できるよう、当社では、Kubernetesといったコンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェアのセットアップも実施しております。
数千ものマイクロサービスを監視することは、モノリシックなシステムと比較して手間がかかります。モノリシックなシステムでは1か所だけを見ればよいのに対し、多くのマイクロコンポーネントを視認し、簡単にデバッグするためには、集中化されたログとダッシュボードが必要です。
コンテナ化したマイクロサービスを監視するオープンツールは数多くあります。当社では、FluentdやLogstashといったツールを活用して、各マイクロサービスからのログを集め、中央データベースに格納しています。データベースが、将来のクエリ用にデータのインデックスを作成し、データを保存します。Kibanaなどのツールを使用して、ログ分析から得られた洞察を示す視覚的なダッシュボードを作成することも可能です。
マイクロサービスにおける共通課題がサービス間の通信です。マイクロサービスは他のマイクロサービスを直接呼び出さず、メッセージブローカーまたはAPIゲートウェイ経由で呼び出します。また、マイクロサービスは、さまざまなバックグラウンド処理によってデータのインポート/エクスポートを行うこともできます。
ユーザーがある操作を行うのに、複数のマイクロサービスが遠隔呼び出しを通したネットワークで互いにやり取りする必要がある場合、ネットワークが利用できなかったり、やり取りに1つでも大幅な待ち時間が発生したりすれば、アプリケーション全体に次々と不具合が及ぶ可能性があります。サーキットブレーカーパターンを使用すれば、重要なサービスのダウンタイムや待ち時間を高度に処理することが可能になります。この方法は、やり取りの負荷を軽減することで、応答しないサービスを回復します。サーキットブレーカーは、不応答数が一定の閾値に達すると、不応答サービスへの呼び出しを行わずにエラーを返します。このサービスへの接続は、定期的なチェックで問題がない場合にのみ回復され、問題がある場合は、回線はオープンのままです。
マイクロサービスの数が増えるにつれ、サービス間通信の処理もより一層困難になっていきます。サービスディスカバリー、負荷バランシング、サーキットブレーキング、認証や個々のマイクロサービスに必要なその他の機能は、すべてのサービスに共通の別のレイヤーにまとめて抽出できます。サービス間通信を処理するためのこういったインフラレイヤーが、サービスメッシュと呼ばれるものです。
サービスメッシュに大多数のネットワークをオフロードすることで、開発者は、ビジネスロジックに集中して取り組めます。どのような言語で書かれたマイクロサービスでも、言語に依存しないサービスメッシュとの連携が可能です。サービスメッシュのオープンソースソフトウェアには、IstioやLinkerd、Conduitがあり、Kubernetes環境にはConduitが最適とされています。
マイクロサービス環境のセキュリティは、モノリシックシステムとは異なる手法で実施する必要があります。ネットワークで行われるサービス間通信は、システムをハッキングする機会を第三者に与えかねません。当社のアーキテクトはセキュリティの専門家と連携し、マイクロサービスの分散環境に構築されたアプリケーションを保護するのにふさわしいツールを使用します。
当社では、カスタムの認可プロトコルを設計できますが、すでに使用できるよう組み込まれたOAuthベースの認可サービスといった、業界標準もあります。
各マイクロサービスの認証および認可は、個別に行えます。このような「信頼することなく、常に確認する」というやり方によって、より厳重なセキュリティが可能になります。
機密情報を扱うサービスに多層セキュリティレイヤーによる対策を講じることで、攻撃者がサービスに侵入しにくくなります。
セキュリティユニットテストを組み込んでCI/CDサイクルにセキュリティを統合すること、また、ロールベースのアクセス制御方法やコンテナ堅牢化対策を行うことで、アプリケーションのセキュリティが向上します。
マイクロサービスを導入する十分な理由があるとはいえ、移行はそう簡単ではありません。マイクロサービスアーキテクチャの実装を成功に導くには、組織全体(ビジネスチーム、開発、ITサポート、セキュリティ)が歩調を合わせ、業務を最適化する準備を整える必要があります。
アプリケーションの設計をするにせよ、既存のアプリケーションに機能を追加するにせよ、あるいは、レガシー・アプリケーションをモダンナイゼーションするにせよ、マイクロサービが実際に必要かどうかを最初に見極めることが重要です。マイクロサービスアーキテクチャ実装の経験豊かなコンサルタントとして、これがいかに複雑な問題であるかを当社は理解しています。当社のチームは、お客様と協力してマイクロサービスがふさわしいかどうかを見極め、確立されたベストプラクティスによってお客様がマイクロサービスアーキテクチャを導入できるようサポートします。
当社は、システム全体を壊してビジネスを中断させることなく、お客様のアプリケーションを段階的に小さなコンポーネントの集合に再編成していく、段階的な変換を推奨しています。
各マイクロサービスは、異なるビジネス機能を担います。そのため、最初のステップは、自己完結型ユニットとしてグループ化できる機能セットを特定することです。複雑なレガシー・アプリケーションには、単独で独立して機能し、他のシステムと独立して展開できるマイクロサービスに変換できるモジュールが数多くあります。
当社として、抽出のためのモジュールを特定し、優先順位付けをしていきます。最もビジネスクリティカルでないモジュール、抽出が容易なモジュール、最も有益なモジュール、または特定のリソース要件を持つモジュールは、早期の段階で適切な機能を追加することができます。モジュールがマイクロサービスに変換されるごとに、モノリスを縮小し、最終的にはマイクロサービスにすることができます。
マイクロサービスは、DevOpsと併用することで一層、機敏性と効率性を向上させることができます。evOpsチームは独立したモジュールに並列で取り組むことができ、これにより開発が加速します。マイクロサービスの数が増えるにつれて、自動化された継続的な統合とデリバリーパイプラインが手動エラーを減らしつつ、段階的なリリースを可能にします。CI/CDパイプラインに統合された継続的なテストは、製品の品質向上を実現します。
マイクロサービスの独立した性質は、DevOpsチームが短時間でより多くを達成するのに役立ちます。これらのアプローチを組み合わせることで、革新を促進し、より大きなビジネス価値を生み出すことが可能となります。
コンテナは、マイクロサービスアーキテクチャに理想的であり、開発からテスト、最終的な展開まで一貫した環境を提供します。各マイクロサービスに仮想マシンを使用すると、膨大なオーバーヘッドが発生し、単一の仮想マシンに複数のマイクロサービスを展開するとサービス間での競合が発生する可能性があります。複数のコンテナが単一のオペレーティングシステムでサポートされるため、マイクロサービスアーキテクチャでは仮想マシンよりもコンテナの使用がはるかに効率的です。
性能の観点からも、コンテナ化は有利です。コンテナは軽量で素早く起動し、マイクロサービスベースのアプリケーションの変動するワークロードにより適しています。細かい実行環境、単一のオペレーティングシステムに複数のコンポーネントを収容できる能力、不規則な作業負荷にも臨機応変に対応できることから、マイクロサービス用にコンテナが優先的に選ばれることが多くなっています。
コンテナ化したマイクロサービスのデプロイを自動化し、さまざまなマイクロサービスをすべて簡単に管理できるよう、当社では、Kubernetesといったコンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェアのセットアップも実施しております。
数千ものマイクロサービスを監視することは、モノリシックなシステムと比較して手間がかかります。モノリシックなシステムでは1か所だけを見ればよいのに対し、多くのマイクロコンポーネントを視認し、簡単にデバッグするためには、集中化されたログとダッシュボードが必要です。
コンテナ化したマイクロサービスを監視するオープンツールは数多くあります。当社では、FluentdやLogstashといったツールを活用して、各マイクロサービスからのログを集め、中央データベースに格納しています。データベースが、将来のクエリ用にデータのインデックスを作成し、データを保存します。Kibanaなどのツールを使用して、ログ分析から得られた洞察を示す視覚的なダッシュボードを作成することも可能です。
マイクロサービスにおける共通課題がサービス間の通信です。マイクロサービスは他のマイクロサービスを直接呼び出さず、メッセージブローカーまたはAPIゲートウェイ経由で呼び出します。また、マイクロサービスは、さまざまなバックグラウンド処理によってデータのインポート/エクスポートを行うこともできます。
ユーザーがある操作を行うのに、複数のマイクロサービスが遠隔呼び出しを通したネットワークで互いにやり取りする必要がある場合、ネットワークが利用できなかったり、やり取りに1つでも大幅な待ち時間が発生したりすれば、アプリケーション全体に次々と不具合が及ぶ可能性があります。サーキットブレーカーパターンを使用すれば、重要なサービスのダウンタイムや待ち時間を高度に処理することが可能になります。この方法は、やり取りの負荷を軽減することで、応答しないサービスを回復します。サーキットブレーカーは、不応答数が一定の閾値に達すると、不応答サービスへの呼び出しを行わずにエラーを返します。このサービスへの接続は、定期的なチェックで問題がない場合にのみ回復され、問題がある場合は、回線はオープンのままです。
マイクロサービスの数が増えるにつれ、サービス間通信の処理もより一層困難になっていきます。サービスディスカバリー、負荷バランシング、サーキットブレーキング、認証や個々のマイクロサービスに必要なその他の機能は、すべてのサービスに共通の別のレイヤーにまとめて抽出できます。サービス間通信を処理するためのこういったインフラレイヤーが、サービスメッシュと呼ばれるものです。
サービスメッシュに大多数のネットワークをオフロードすることで、開発者は、ビジネスロジックに集中して取り組めます。どのような言語で書かれたマイクロサービスでも、言語に依存しないサービスメッシュとの連携が可能です。サービスメッシュのオープンソースソフトウェアには、IstioやLinkerd、Conduitがあり、Kubernetes環境にはConduitが最適とされています。
マイクロサービス環境のセキュリティは、モノリシックシステムとは異なる手法で実施する必要があります。ネットワークで行われるサービス間通信は、システムをハッキングする機会を第三者に与えかねません。当社のアーキテクトはセキュリティの専門家と連携し、マイクロサービスの分散環境に構築されたアプリケーションを保護するのにふさわしいツールを使用します。
当社では、カスタムの認可プロトコルを設計できますが、すでに使用できるよう組み込まれたOAuthベースの認可サービスといった、業界標準もあります。
各マイクロサービスの認証および認可は、個別に行えます。このような「信頼することなく、常に確認する」というやり方によって、より厳重なセキュリティが可能になります。
機密情報を扱うサービスに多層セキュリティレイヤーによる対策を講じることで、攻撃者がサービスに侵入しにくくなります。
セキュリティユニットテストを組み込んでCI/CDサイクルにセキュリティを統合すること、また、ロールベースのアクセス制御方法やコンテナ堅牢化対策を行うことで、アプリケーションのセキュリティが向上します。
当社のあるお客様が使用されていたアプリケーションは、製品設計や開発に使われるラピッドプロトタイピングツールでした。このアプリケーションは、コンポーネントを個別に開発・拡張できないクライアントやサーバーと強連結したモノリシックシステムでした。当社は、技術スタックを評価し、欠陥を把握した上で新しいソリューションを提案するように依頼を受けました。
当社が行った技術的評価から、業務遂行の大きな障害となっているだけでなく、ソースコードのメンテナンス、コード品質、アプリケーションの全体的な拡張性に関する深刻な懸念が明らかになりました。当社は、マイクロサービスモデルのレイヤーによるN層アプリケーションとして、システムを再設計するように提案しました。これなら、モジュールがそれぞれ独立し、他のモジュールとの結び付きは弱連結です。サービスモデルごとにデータベースを作成する代わりに、ハイブリッドマイクロサービスアーキテクチャで単一の共有データベースを使用することにしました。
また、新たなアプリケーションライフサイクルの完全な自動化も提案しました。マイクロサービスの設計とデプロイは、Jenkinsによって自動化するようにしました。IaC(Infrastructure as Code)を導入すれば、インフラのデプロイ、監視と管理も自動化できます。アプリケーションをDocker化することで資源利用の削減と迅速な開発が可能になり、さらに、オーケストレーションツールによってコンテナのライフサイクル管理を簡素化できます。最後に、ELK Stackによる、継続的なインフラ監視とログ管理を提案しました。