・マイクロサービスとは
・マイクロサービスの特徴
・従来の構成（モノリシック構成）
・マイクロサービスの構成
・マイクロサービスのメリット
・OSや言語、スケーリングが自由
・必要最低限の影響だけでコード更新が可能
・容易なデプロイ
・マイクロサービスのデメリット
・サービス間の繋がりが複雑
・全てのサービスで統一された設計思想が必要
・マイクロサービスをより強固にするために
・コンテナ
・サービスメッシュ
・APIマネジメントサービス
マイクロサービスとは
マイクロサービスとは、細かなサービスに分割されたアプリケーションを結合させて１つのビジネス機能を実現させるソフトウェア開発の技法であり、
2014年にThoughtWorks社のマーチン・ファウラーとジェームス・ルイスによって提唱された。
１つの１つのサービスはそれぞれ独立して完結しており、他のサービスに影響することなく開発が可能になっている。
マイクロサービスの特徴
マイクロサービスの特徴を従来の構成と比較してご紹介します
従来の構成（モノリシック構成）
本の注文処理がある場合、従来の構成では１つのアプリケーションの中に在庫確認〜発注処理を設けている。
仮に別の注文処理を作る場合、新たにアプリケーションを作成し、在庫確認〜発注処理を作ることになる。
マイクロサービスの構成
一方マイクロサービスの場合、機能を１つ１つ分解し、独立させている。
それによって新たに注文処理を作る場合でも、独立した機能を使用することができるため、開発コストを減らすことが可能。
それだけでなく、サービス間は疎結合（お互いの関係が薄い）ため、影響を少なくして改修を行うことが可能。
各サービス間はREST APIやgRPC(Google Remote Procedure Call)でやり取りされており、どの機能からも呼び出し可能な通信を行なっている。
マイクロサービスのメリット
マイクロサービスは「独立」という点が大きな特徴のため、それに対してどのようなメリットがあるのかご紹介します。
OSや言語、スケーリングが自由
各サービスを独立して機能することは、コンテナとの相性が抜群に良い。
それによりOSや言語、スケーリングをそのサービスに合わせて自由に選択することができる。
特定のサービスに一番適切なOSや言語が選択できるため、より良い品質を提供でき、
スケーリングについては、過度なトラフィックが発生するサービスにはCPUやメモリを増強したり、逆にほとんど使われないサービスには少ない量を選択できるため、サービスに掛るコストを適切にコントロールできる。
サービス間のやり取りはREST APIなどで行われるため、通信方式だけ気を付けるだけで、その他の点は専ら自由に設計が可能となっている。
必要最低限の影響だけでコード更新が可能
サービス間は疎結合で設計を行うため、他のサービスへの影響はかなり少なくなっている。
そのため特定の機能の修正による影響調査やテストを最小限に抑えてコードの更新が可能となっている。
容易なデプロイ
アプリケーションが１つにまとめられているモノリシック構成の場合、特定のサービスを改修した際、他のサービスも巻き込んでビルドデプロイを行う必要がある。
マイクロサービスでは、各サービスは独立しているため、個別のビルドデプロイが可能。
そのため、他の機能を気にすることなくサービスの改修、拡張が容易となり、継続的な開発・継続的なリリース（CI/CD)が可能となっている。
マイクロサービスのデメリット
マイクロサービスは「独立」という大きなメリットがあるが、逆にそれがデメリットになっている側面がある。
サービス間の繋がりが複雑
特定のサービスは、REST APIやgRPCによって様々なサービスを呼び出し、また様々なサービスから呼び出される。
その関係が大量に発生することによって、サービス間の繋がり、どのサービスがどのサービスを使用しているかなど、
管理が複雑になる。
また、特定のサービス以外からのリクエストを拒否するなどのセキュリティを行う必要があり、トラフィック管理のツールの導入が必須となっている。
全てのサービスで統一された設計思想が必要
各サービスの関係は疎結合で作られる必要があり、設計思想を明確にして開発を行わなければならない。
結合度合いが強くなれば、それだけ独立性から離れ、マイクロサービスのメリットが失われていく。
マイクロサービスを導入するプロジェクトは、大きなプロジェクトになりやすく、携わる開発者の数も膨大になりがちになる。
その大きなプロジェクトの中で、統一された設計思想でマイクロサービスを実現することはかなりの難易度になっている。
マイクロサービスをより強固にするために
マイクロサービスのメリットを増やし、デメリットを抑えるための様々なアーキテクチャが存在する。
それらを使用することで、コスト削減や迅速なソース修繕、効率的な管理運用ができるマイクロサービスを構築することができる。
コンテナ
前述にも記載したが、マイクロサービスはコンテナとの相性が抜群で、マイクロサービス＝コンテナでの構築というのが常識と言っても過言ではない。
またGKEなど、Kubernetesサービスを利用することでコンテナの管理や障害時の迅速な復旧が可能となり、ビジネス機能として品質の高いサービスを提供できる。
サービスメッシュ
各サービスはREST APIで複雑に絡み合っているため、それらのトラフィック管理、セキュリティが必須となっている。
トラフィック管理の手段の一つに、各サービスの間にApigeeのようなAPIゲートウェイを配置する手段がある。
これによって、サービス間の繋がりをAPIゲートウェイ一つで管理することができるが、マイクロサービスの規模が大きくなればなるほど、
そのAPIゲートウェイの重要性が増し、超高可用性が求められる。
それを回避するために発案されたのがサービスメッシュである。
サービスメッシュとは、各サービスにサイドカーとして取り付けられ、サービス間のトラフィック制御やセキュリティ、可観測性の確保を可能にしている。
サービスメッシュの代表的なアプリケーションにIstioがある。
APIマネジメントサービス
APIマネージメントサービスの役割は主に、分析、アクセス制御、収益化、開発者ワークフローなど、API プログラムの制御を集中管理することである。また、そのマイクロサービスが外部に公開するサービスの場合、認可機能といったセキュリティ機能を設けなければならない。
そういった機能を実現してくれるのがApigeeやAmazon API GatewayといったAPIゲートウェイである。
