Zenn
🍣

マイクロサービス化のトレンドについて

2022/11/09に公開
#
サーバレス
#
マイクロサービス
idea

はじめに

  • システムを構築するにあたり、よく話題となるのが、「マイクロサービスアーキテクチャ」や「サーバレス」というキーワードが挙げられる。
  • 昨今の「マイクロサービスアーキテクチャ」のトレンドについて考察する。

モノリシックなシステムのクラウド移行

  • 既存のレガシーでモノリシックなシステムを、マイクロサービスアーキテクチャ化して、API提供し、クライアント要望に沿う形で、組み合わせができるようにし、汎用性を高める取り組みを行う。また、バックエンドはサーバレスを採用し、利用頻度に応じた課金体系を用いることでコスト低減に取り組むというシナリオがトレンドである。
  • 上記シナリオをクライアントが積極的に採用するというよりはむしろ、モノリシックな環境をクラウド移行を検討する段階で、自然とマイクロサービスアーキテクチャーの形となっている。

移行のユースケース

  • 例えば、「既存のモノリスなオンプレミスシステムのクラウド移行を実施したい。クラウドプラットフォームを選定し、AWSを利用することとなった。」というユースケースで検討する場合、以下機能群とAWSサービスを選定する形となる。
    • フロントエンド: ユーザ認証(Cognito)、UI/UX(Amplify)
      • フロントエンドはユーザ認証して、バックエンドのAPIを叩くくらいで複雑な機能は実装しない。
    • API層: バックエンド呼び出し(Amazon API Gateway)
      • バックエンドに複数のサービスがある場合は、BFF(Backend For Frontend)の形をとる。
    • バックエンド: サーバレスアーキテクチャ(Lambda, Fargate)、データベース(Aurora)
    • バックエンド呼び出しのAPI負荷が高い場合には、handlerで非同期処理が可能な構成を追加。
  • メジャーなクラウドサービスへの移行を検討しデザインすると、フロントエンド - API - バックエンドといった自然とマイクロサービスアーキテクチャの形となる。

マイクロサービスの運用

  • 移行に伴いマイクロサービスの運用方法を検討する必要がある。
  • マイクロサービス化を進めるにあたり、サービスの粒度を決める必要がある。粒度が細かくなると、システム数が多くなり、システム間のIF(API)の数が多くなる。また、深い階層のマイクロサービスシステムがダウンした場合、サーキットブレーカー等のワークアラウンド手段は存在するが、実装するのはかなり難度が高い。
    • サーキットブレーカーとは、マイクロサービスの階層中にあるサービスの障害を検知した場合に、通信を遮断、サービス復旧時の通信を復旧させる方式。
    • Service-1 -> Service-2 -> Service-3 という階層の構成の場合、Service-3が障害の場合、2 -> 3の通信を遮断する。
    • この場合のワークアラウンドとして正しいと思われる動作としては、Service-2がService-1へ障害発生中という情報を伝達し、Service-1でエラーレスポンスを返す。Service-1側で入り口からアクセスを停止させないと、結局、キューなどでアクセスを溜め込むことになる。Service-1だけがOKでもサービスとしては完結しないため。
    • 比較的単純な3階層のマイクロサービスでも上記の通り複数の処理が走ることになる。ゆえに、これ以上の複数層の運用は困難と想定される。
  • 階層構造APIのアーキテクチャは運用が難しいのではないだろうか。上記のとおり、マイクロサービス提供側で複数階層運用は困難となるため、提供されているAPIの連係をクライアント側で制御する形でリリースされるケースが割と多くなる。サービス提供者側は単独で動作するAPIをクライアントへ開放する形が主流。

マイクロサービス監視

  • HW監視は重要視されない、サーバレス構成を取る可能性もあるし、クラウドであるため99.9％以上の稼働率は保証される、かつリージョン内での冗長構成はデフォルトなので、そこまで重きは置かなくなる。
  • これまでの死活監視から、もう一段上の運用が必要になる。例えば、第一階層のサービスがAPI経由で提供されていた場合、APIのレスポンス時間等、サービス品質を図ることが重要になる。
  • SREのパフォーマンスが充分に機能していることの監視を行う必要がある。

さいごに

  • クラウドサービスへの移行をした段階で「フロントエンド-API-バックエンド」のマイクロサービスアーキテクチャの形となる。
  • クラウドサービスへの移行した後の運用の難易度が上がるため、どういう監視・運用を行うか、また現実に運用実現性を考慮した移行プランニングが必要となる。

Discussion