Kubernetesとクラウドネイティブアプリケーションへの道 – SAP Commerceの例

イノベーションの文化を生み出す企業は、強い競争力を持っています。事前に計画を立てていない場合、数か月前まで持っていた市場優位性を突然失う可能性があります。そして、優れたアイデアを素早く実現することが重要です。実際に、お客様のアイデアと成功の間には、他との差別化には繋がらない重労働がたくさんあります。この課題の解決策の一つは、仮想マシン (VM)よりも高いレベルの抽象化に移行することです。しかしながら、Kubernetesへの移行は、大きな文化的変化を生み出す可能性があります。このブログ記事では、以前のブログで触れたAmazon EC2を基盤としたSAP Commerce システムをKubernetesを基盤としたシステムに素早く切り替える方法を紹介します。

概要

デプロイメントから始めて、Amazon Cloud Development Kit (CDK)がInfrastructure as Codeにとって非常に強力な理由を説明します。次に、完全マネージドのコントロールプレーンとノードグループ、そしてこれらの機能が他との差別化に繋がらない重労働からどのように解放してくれるかを説明します。最後に、コンテナ化されたSAP Commerce アプリケーションをAmazon Elastic Kubernetes Serviceに展開することが如何に容易かを説明します。

前提条件

SAPからSAP Commerce ソフトウェアをダウンロードして、Amazon S3 バケットに格納しておきます。
SAP Commerceをコンテナ化します。これを自動化するために、AWSサンプル GitHubにあるSAP Commerce リポジトリを参照しましょう。Docker イメージを作成するオプションを選択するだけで、Amazon Elastic Container Registry (ECR)にイメージを自動的にアップロードできます。

AWS Cloud Development Kitを使用したAmazon EKSへのSAP Commerceのデプロイメント

インフラストラクチャーをプロビジョニングして、SAP Commerceを展開するには、まず、AWSサンプル GitHubにあるCDK for SAP example リポジトリのサンプルコードをクローンすることから始めましょう。“Getting started with the AWS CDK”ガイドを参考にAWS CDKを設定するか、GitHub リポジトリにあるREADMEに従ってください。展開が完了するのを待っている間に、使用したいくつかのコンセプトについて詳しく見ていきましょう。

Cloud Development Kit

以前のブログでは、Amazon EC2へのSAP Commerceの展開にAWS CloudFormationを使用しました。このブログではCDKに重点を置いており、なぜこうしたのかを見ていきましょう。TypescriptでCDKを使用してAmazon Virtual Private Cloud (VPC)を展開するコードは次のようになります。

    this.vpc = new ec2.Vpc(this, "VPC", {
      maxAzs: 3,
      cidr:"10.20.0.0/16",
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: 'commerce-public',
          subnetType: ec2.SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: 'commerce-private',
          subnetType: ec2.SubnetType.PRIVATE,
        },
        {
          cidrMask: 24,
          name: 'commerce-database',
          subnetType: ec2.SubnetType.ISOLATED,
        }
      ],
      natGateways: 2,
    });

ご覧いただいた通り、これは本当に単純です。AWS CloudFormationでは453行のコードが、VPC コンストラクトを活用したら31行のコードになりました。AWS CDKがコミュニティに衝撃をもたらした理由が分かります。DevOps チームが既に使い慣れているプログラミング言語を使用するだけです。ここではTypescriptを使用していますが、AWS CDKではJavaScript、JAVA、Pythonを使用してもインフラストラクチャーを定義できます。これは本当に興奮する分野であり、多くの新しいコンストラクト、パターン、プログラミング言語を頻繁に追加しています。

コントロールプレーン

コントロールプレーンはKubernetesの頭脳であり、クラスター上で実行されているすべてのコンテナとポッドの全体像を把握できます。これまで、この管理には非常に専門的なスキルセットが必要でした。Amazon EKSであれば、コントロールプレーンの展開に必要なものは、次のCDKのコードスニペットだけです。さらに、Amazon EKSは、高可用性 (HA)を確保するために複数のアベイラビリティゾーン (AZ)をまたがってKubernetesのコントロールプレーンインスタンスを実行します。加えて、異常なコントロールプレーンインスタンスを自動的に検出して置き換え、自動化されたバージョンアップグレードとパッチ適用を提供しています。

そして、これをCDKで行うためのコードが次です。

    //Create EKS cluster
    this.cluster = new eks.Cluster(this, "Cluster", {
      vpc: vpc,
      defaultCapacity: 0,
      version: eks.KubernetesVersion.V1_17,
      outputMastersRoleArn: true,
      outputClusterName: true,
    });

マネージド型ノードグループ

コントロールプレーンに加えて、マネージド型ノードグループを展開します。Amazon EKSのマネージド型ノードグループを使用すれば、Kubernetes アプリケーションを実行するためのコンピューティング能力を提供するAmazon EC2 インスタンスを個別にプロビジョニングまたは登録する必要がありません。すべてのマネージド型ノードは、Amazon EKSが管理するAmazon EC2 Auto Scaling グループの一部としてプロビジョニングされます。

そして、これをCDKで行うためのコードが次です。

    //Add node group 
    this.cluster.addNodegroupCapacity("nodegroup", {
      instanceType: new ec2.InstanceType("c5.2xlarge"),
      minSize: 2,
      maxSize: 8,
      subnets: { subnetType: ec2.SubnetType.PUBLIC },
    });

Aurora Serverless データベースの展開

2017年に、SAP Hybris向けのAmazon Auroraの認定を発表しました。この例では、Amazon Aurora Serverlessを使用しています。以前のブログで触れたように、これはAmazon Auroraのオンデマンド自動スケーリング設定です。このデータベースは、アプリケーションのニーズに基づいて自動的に起動、停止、容量の拡大と縮小を行います。データベースインスタンスを管理することなくクラウドでデータベースを実行でき、非本稼働環境に最適です。ドキュメントを読んで、Amazon Aurora Serverlessの使用の詳細を確認してください。

繰り返しとなりますが、CDKのコードスニペットは本当に単純です。このcdk-rds モジュールにあるサーバレスコンストラクトは、このブログの執筆時にリリースしました。これにより、少なくとも100行以上のコードを記述する必要がなくなり、申し分のないタイミングでした。

SAP Commerce イメージの展開

SAP CommerceのDocker イメージをこのクラスターに展開しましょう。Helm チャートやcdk8s Chartなど、AWS CDKを使用してDocker イメージをクラスターに展開する方法は多数あります。ここでは、マニフェストを非常に単純にしており、このクラスターにDocker イメージを適用するために、cluster.addManifest コンストラクトを使用しています。

デプロイメントの出力には、EKS クラスターにアクセスするための重要な出力もいくつか含んでいます。ClusterConfigCommandは、kubeconfigを更新するコマンドを表示し、別のkubectl コマンドを実行できます。 cdk-eks.eksloadbalancerは、hybris 管理コンソールにログインするためのApplication Load Balance (ALB)のホスト名を表示します。URLにアクセスするには、ポート番号8088を追加する必要があります。

クリーンアップ

インフラストラクチャーのクリーンアップは簡単です。cdk destroy コマンドを実行するだけです。ただし、Amazon S3のSAPバイナリーやAmazon ECRのコンテナイメージは個別に削除する必要があることを忘れないでください。

結論

以前のブログでは、進化するアーキテクチャの重要性を紹介しました。このブログでは、SAP Commerce アーキテクチャをKubernetesを基盤としたアーキテクチャに切り替える方法を紹介しました。また、デプロイメント方法をAWS CloudFormationからAWS CDKに変更しています。

Amazon ESK スタック用の85行のコード、Amazon RDS スタック用の37行のコード、Amazon VPC スタック用の37行のコードがあり、SAP Commerce アプリケーションのKubernetes クラスターへの簡素化した展開のための合計で160行に満たないコードがあります。これは本当に単純であり、ウェブアプリケーションの作成と運用に必要な他との差別化に繋がらない”重労働”を削減するためにAWSがどれだけ役に立つかを表しています。

今回は、開発のためにAmazon EKSで何ができるかを垣間見ただけです。Amazon EKS上のSAP Commerceのクラスタリングに関して具体的な詳細を深堀するために、別のブログでフォローアップする予定です。SAP on AWS ブログをご期待ください。このブログが興味深く、私たちと同じように楽しんでいただけたら幸いです。コードをダウンロードして試してみてください。もしご質問がある場合、あるいはSAPシステムの選択肢を知りたい場合は、sap-on-aws@amazon.comに問い合わせるか、aws.com/sapを訪問して詳細を確認してください。今日からAWSでの構築を開始し、楽しんでください！

翻訳はPartner SA 河原が担当しました。原文はこちらです。

Amazon Web Services ブログ