SaaS DevOpsの深掘り：マルチテナント展開の自動化

Pulisher : Strategic Tech Center チャン・セジョン
Description : SaaS環境でのDevOps戦略について紹介するセッション

はじめに

DevOps関連の仕事をしていて、SaaS環境でのDevOps戦略はどのようなものなのか、また、他の人はどのようなツールを使ってDevOpsアーキテクチャを構成し、デプロイしているのか気になり、そのセッションで知りたい疑問を解消できるのではないかと思い、申し込みました。

セッションの概要紹介

SaaS環境のオンボーディング、デプロイメント、テナントのアップデートを支援する様々なツール、技術、サービスについて学び、事例を通じ例題を通じてDevOps戦略を学びます。

基本的にTest環境の役割をすることができるBasic Tierを置いて、その他の残りのサービスごとに違うTierを持つように構成します。MSA環境でサービスするため、各サービスごとに使うDynamoDB、Amazon SQSなどは独立して別々に使います。

自動化するための自動化ツールはTier ConfigurationとTenant ConfigurationはTerraformとHelmを使います。

Tenant onboardingとDeployment PipelineはArgoとFluxを使用しました。

Argoを使ってTerraformとHelmを呼び出してAWS ResourceをデプロイしてResourceの生成や管理をします。

FluxはKubernetes ResourceをデプロイしてResourceを生成して管理します。

開発者はソースをビルドし、そのビルドはDocker ImageをECRにPushします。 そして、Helm Chartにバージョンを更新します。 Fluxは変更されたバージョンを見てECRからそのDocker ImageをPullしてKubernetesにデプロイします。

Serverless自動化ツール要素としては、サーバーレスアプリケーションをビルドして実行する開発者環境を改善するツールキットであるAWS SAMがあります。

時差的な展開にはAWS CodePipelineとAWS Step Functionを使います。

Amazon DynamoDBにはTenantとTier構成情報があり、AWS API GatewayとAWS Lambdaでサービスをプロビジョニングします。

時差的なデプロイ段階では、デプロイPipelineでソースビルドが行われ、これが最初のBasic Tierにデプロイされます。デプロイ後、異常がないかをモニタリングします。

異常がないことを確認したら、承認をして次のTenantサービスにデプロイしてデプロイ作業を終了します。

最後に要点をまとめると

自動化はSaaSアジャイルの中核であり、アプリケーション実証モデルの設計とデプロイメント戦略の構成が重要です。

また、すべてのレイヤーに対して単一のソフトウェアバージョンを維持・管理する必要があり、レイヤー間の移動時に追加の自動化が必要です。

セッションを終えて

上記の内容以外にもAWSサーバーレス基盤環境にAWSコードパイプライン、AWS Step FunctionsやAWS CloudFormationを活用したDevOps戦略も説明する部分がありました。

韓国ではGithub ActionやJenkinsなどでビルドしてArgoでデプロイする戦略が一般的ですがこのセッションではAWS CodeBuildでビルドしてAWS ResourceはArgoでデプロイ、KubernetesはFluxでデプロイする戦略がとても印象的でした。

実際にその戦略で運用をすると、管理ポイントが多く、運用が容易ではないと思いますが、そのような運用のノウハウまで聞きたかったと、少し残念な気持ちも残りましたが、聞いておいて損はないセッションでした。