はじめに

このブログでは、オンプレミスの SAP Commerce 導入において、お客様が経験している最も一般的な問題について説明します。Amazon Elastic Kubernetes Service 上でブルー/グリーン・デプロイを実現し、SAP Commerce アプリケーションをより速く、より安全に実装するための具体的な方法を説明します。
デプロイ手順は、SAP の公式ドキュメントに記載されている、クラスタでのローリングアップデートの実行に関する内容に基づいています。SAP Commerce アプリケーションは、ブルー/グリーン・デプロイ戦略をサポートする Helm チャートを使用してデプロイされます。さらに、AWS CodeCommit、AWS CodePipeline、AWS CodeBuild を使用したシンプルな継続的インテグレーションと継続的デリバリー/継続的デプロイメント (CI/CD) パイプラインで、デプロイの自動化を実現します。

前提条件

このブログでは、SAP Commerceを実行するために必要なインフラがすでにプロビジョニングされていることを前提としています。以下のコンポーネントがすでに導入され、設定されていることが想定されます。

• パブリック、プライベート、および分離されたサブネットを持つ Amazon Virtual Private Cloud (VPC) が作成されている。
• Amazon EKS クラスタは、定義された Amazon VPC でプロビジョニングされている。
• AWS Load Balancer Controller が Kubernetes クラスタにデプロイされている。
• Amazon Route53 パブリックホストゾーンが作成されている。
• 作成された Amazon Route53 ホストゾーンで構成された ExternalDNS が Kubernetes クラスタにデプロイされた。
• Amazon VPC サブネットに Amazon RDS for MySQL がプロビジョニングされ、プライベートサブネットから到達できる。
• MySQL データベースのデータベース スキーマは、SAP Commerce 用に作成されている。

オンプレミス環境における導入の課題

SAP Commerce は SAP が提供する人気な e コマースプラットフォームで、エンタープライズの Java ウェブアプリケーションで構成されています。従来、オンプレミス環境では、SAP Commerce はサーバーまたは VM で構成された変更可能なインフラストラクチャにデプロイされています。SAP Commerce の本番環境は、顧客の需要に合わせて拡張できるように、複数のアプリケーション サーバー ノードで構成されています。

自動化された CI/CD パイプラインは、新しいリリースごとにクラスタノードレベルでローリングアップデート戦略を実行します。各ノードは顧客のリクエストに対応しないように、ロードバランサーから順次削除され、新しいリリースにアップグレードされます。ノードのアップグレード後、ノードはロードバランサーに戻され、新しいリリースのコードベースを使用して顧客のリクエストに対応できるようになります。

クラスタは複数のアプリケーションノードで構成されるため、デプロイが完了し、すべてのクラスタノードが新しいバージョンにアップグレードされるまで、数時間かかることがあります。革新的なソリューションに迅速に対応し、市場での競争力を維持する必要がある e コマース事業やマーケティングチームにとって、長時間のデプロイは大きな支障となります。

ブルー／グリーン・デプロイによる解決策

Amazon EKS上 で SAP Commerce のワークロードを実行することで、ブルー／グリーン・デプロイを含む複数のデプロイ戦略を実行することが可能です。ブルー/グリーン・デプロイ技術は、アプリケーションの異なるバージョンを実行している 2 つの同一環境間でトラフィックをシフトさせることで、アプリケーションのリリースを可能にします。ブルー／グリーン・デプロイメントは、ダウンタイムやロールバック機能など、ソフトウェアのデプロイに関連する一般的なリスクを軽減することができます。

デプロイの手順

新しいリリース（v2）がデプロイされる前に、実際には1つのリリース（v1）のみがクラスタにデプロイされます。

データベースレベルでは、SAP Commerce タイプのシステム定義を使用することで、同じデータベーススキーマ上で異なるリリースの複数のコードベースに関連する複数のスキーマ変更を処理することができます。新しいリリース (v2) がデプロイされると、2 つの Kubernetes ジョブが順番に作成され、次のようになります。

• 最新リリース (v2) 用の新しいタイプのシステムを作成する
• システムの新しいタイプ (v2) に対してシステムアップグレードを実施する

ブルー/グリーン・デプロイ戦略により、新しいリリース (v2) は Amazon EKS クラスタの現在のバージョン (v1) と共に、新しいグリーンのスロットにデプロイされます。両方のバージョンは、同じ本番環境内の異なるスロット（青と緑）で同時に利用できるようになります。この時点で、エンドユーザーは青いスロットで現在の本番リリース (v1) を閲覧し続け、テストチームは緑のスロットで新しいリリース (v2) にアクセスし、テスト戦略を実行することができます。

新しいリリース (v2) が本番システムに昇格できるようになると、ロードバランサーでエンドカスタマーのリクエストをグリーンスロットに、古いリリース (v1) を青いスロットに振り分けるスイッチが実行されます。エンドユーザーはすぐに新しいリリース (v2) のアプリケーションにフルスケーリングでアクセスすることができます。

古いリリース (v1) はまだクラスタ内で利用可能で、新しいリリース (v2) で問題が発生した場合には本番利用に切り換えることができます。そうでない場合は、青いスロットを廃止してリソースを解放し、新しいリリースのデプロイを実行できるようにすることが可能です。

アーティファクト

Helm チャートよりアーティファクトを構成し、アプリケーションのデプロイと CI/CD パイプライン定義を対応し、デプロイのプロセスを自動化します。

Helm チャート

SAP Commerce on Kubernetes (Amazon EKS) によるブルー/グリーン・デプロイ戦略をサポートするために、Helm チャートが実装されています。Helm チャートには、CI/CD パイプラインのデプロイ自動化において、Helm チャートのインストールとアップグレードを実行するためのスクリプトが付属しています。

デプロイのパイプライン

SAP Commerce アプリケーションをデプロイするために、AWS CodePipeline と AWS CodeBuild を使用して helm チャートをインストールおよびアップグレードするためのパイプラインが定義されています。このパイプラインは、AWS CodeCommit で release-* ブランチが作成される際に作成と開始されます。AWS CodePipeline によるマルチブランチ戦略に対応するため、このソリューションが採用されました。

重要な注意事項

Helm チャートは、Kubernetes Namespace と Kubernetes Service Account の作成をサポートしています。このブログでは、これらのリソースが Helm チャートのインストールの前提条件として作成されていることを想定しています。Helm チャートのデプロイ時に Namespace と Service Account の作成を処理するパイプラインを設計する際に、追加のロジックを実装することができます。

Helm チャートを初めてデプロイする際に、最初のリリースのタイプ・システムは DEFAULT であると仮定します。これにより、そのリリース専用のタイプ・システムを作成することなく、デプロイすることができます。次のリリースは、そのリリースと同じ名前でデプロイされる前に作成される特定のタイプシステムにデプロイされます。

新しいリリースのタイプ・システムは、データベースに存在しないことが前提となっています。つまり、新しいリリースをデプロイする際には、常に新しいタイプ・システムが作成されることになります。独自のパイプラインを設計する場合、新しいリリースのタイプ・システムが必要なときだけ作成されるようにメカニズムを実装する必要があります（例：AWS Lambda 関数を使用する）。

インストールガイド

SAP Commerce のブルー/グリーン・デプロイ用のパイプラインを設定するには、github リポジトリで公開されているインストールガイドに従ってください。AWS リソースをすべて削除し、追加コストを発生させないようにするために、クリーンアップの手順に従ってください。

まとめ

ブルー/グリーン・デプロイ戦略は、e コマースにおける新しいリリースのデプロイをスピードアップするためのゲームチェンジャーとなりえます。このブログが、SAP Commerce のデプロイ パイプラインを現代化し、改善するためのヒントになることを願っています。

次のステップ

このブログでは、Helm とシンプルなデプロイメントパイプラインを使用して、SAP Commerce アプリケーションをデプロイするためのシンプルな概念実証を説明します。SAP Commerce の本番ワークロードを管理するには、監視、観測性、セキュリティ、パフォーマンス チューニングなどの追加ステップが必要です。

翻訳は Specialist SA アッシュが担当しました。原文はこちらです。