Yemeksepeti: サーバーレスアーキテクチャへの当社の移行

AWS コミュニティヒーローの Onur Salk 氏から、自社のサーバーレスアーキテクチャへの移行をどのように支援したかについて、次のようなゲスト投稿が寄せられました。

— Jeff;

私は AWS コミュニティヒーロー、AWS 認定ソリューションアーキテクト – プロフェッショナル、トルコの AWS ユーザーグループの主催者である Onur Salk と申します。私はヒーローとして、AWS の経験と知識を個人ブログやコミュニティでの出会いを通じて共有していきたいと思っています。本日は、当社 Yemeksepeti の事例と、サーバーレスアーキテクチャへの移行についてお話したく思います。

Yemeksepeti の事例
Yemeksepeti はトルコ最大のオンライン注文企業です。ユーザーは、提携先のネットワークレストランから食材の注文を行うことができ、手数料はかかりません。Yemeksepeti では、スケーラブルでパフォーマンスと費用効率の高い、世界中に分散したサービスをセットアップする必要がありました。当社は、サーバーレスアーキテクチャを設計することで、サーバーの管理について心配することなく、チームから多くの運用面の負担を取り除くことができると考えています。つまり、コードの大規模な実行に集中できるということです。

Yemeksepeti.com では、約 4 年前に Joker と呼ばれるリアルタイムの割引システムを開発しました。このシステムの目的は、レストランに関して通常ないような割引を顧客に提案することです。元の Joker プラットフォームは .NET で開発され、その REST API を使ってウェブサイトやモバイルデバイスと統合されました。世界 34 か国で営業している関連会社も顧客にリアルタイムの Joker 割引を提供できるように、関連会社に対してプラットフォームの API を公開することを求められました。

最初はコードを共有し、関連会社にアプリケーションを統合させることを考えました。ただし、他のほとんどの国では異なる技術スタック (プログラミング言語、データベースなど) を使用していました。当社のコードを使用することで、最初は関連会社による開発が迅速化する可能性がありますが、不慣れなシステムを管理しなければなりません。実装がより簡単で、管理費用がより安い統合方法を見つける必要がありました。

当社の要件
これはグローバルなプロジェクトであり、次の 5 つの重点領域がありました。

• 管理の容易さ
• 高可用性
• スケーラビリティ
• 複数のリージョンでの使用
• 費用のメリット

複数の異なる処理モデルについてこれらの重点領域を評価した結果を、次のマトリックスに示します。

当社は Faas (Functions as a Service) を使用することに決定しました。以下のサービスを使って、Europe (Ireland) リージョンでプロジェクトを開始しました。

• Amazon Virtual Private Cloud
• Amazon API Gateway
• AWS Lambda
• Amazon Relational Database Service (RDS)
• Amazon Simple Storage Service (S3)
• Amazon CloudWatch
• Amazon Elasticsearch Service

アーキテクチャ
当社のアーキテクチャを次に示します。

Amazon VPC: 当社は Amazon VPC を使用してプライベートネットワークでリソースを起動します。

Amazon API Gateway: 開発段階中、Europe (Ireland) リージョンでサービスの開発を開始しました。その当時、AWS Lambda は Europe (Frankfurt) で利用できませんでした。当社は 2 つの API を作成しました。1 つはウェブ統合用、もう 1 つは管理インターフェイス用です。JSON ウェブトークン (JWT) を使用したカスタム認証により、API 用にトークンベースの認証を可能にしました。マッピングテンプレートを使用して変数を Lambda 関数に渡しました。

開発段階では、各 API に対してテストステージのみがありました。

本稼働段階中に、AWS Lambda がフランクフルトで利用可能になりました。そこにサービスを移動し、トルコから低レイテンシーのアクセスのメリットを受けることにしました。API Gateway Export API 機能を使用して設定を Swagger 形式でエクスポートし、それをフランクフルトにインポートしました (インポート前に、エクスポートされたファイルのリージョン定義を eu-central-1 に変更しました)。その後、実稼働ステージを作成し、ステージ変数を使用して Amazon RDS インスタンスのデータベース定義 (ホスト、ユーザー名など) をパラメーター化しました。また、カスタムドメイン名を使用したいと考えました。ドメイン用に SSL 証明書を購入した後で、Amazon API Gateway コンソールでカスタムドメイン名を作成し、CloudFront ディストリビューション名のエイリアスを作成しました (Amazon API Gateway はバックグラウンドで Amazon CloudFront を使用します)。最後に、API コール、レイテンシーなどについて Amazon CloudWatch のログ記録を有効にするために IAM ロールを作成しました。

Get_Joker_offer リソースのメトリックス:

AWS Lambda: 開発段階中に、Python を使用してサービスを開発し、CloudWatch Events Lambda トリガーを使用して API メソッドとスケジュールされたタスクを統合するために、65 個の関数を作成しました。Lambda VPC の統合が実稼働段階中に利用可能になったため、関数をフランクフルトリージョンにアップロードし、VPC と統合しました。

Get_joker_offer Lambda 関数の呼び出しカウント (ピークは昼食時および夕食時に一致します (空腹時)):

Amazon RDS: 開発段階中に、Amazon RDS for PostgreSQL の使用を選択しました。サービスをテストするために、1 つの AZ RDS インスタンスを作成しました。実稼働段階中に、API と関数をフランクフルトに移行したため、データベースを移動する必要がありました。インスタンスのスナップショットを作成し、RDS のスナップショットのコピー機能を使用して、データベースを正常に移動しました。VPC で、実稼働用のマルチ AZ インスタンスと、テスト目的のシングル AZ インスタンスの 2 つのインスタンスを起動しました。API ステージ変数で、ステージングを適切なインスタンスにマッピングするため、RDS インスタンスのエンドポイント名を定義しました。また、両方のインスタンスで自動バックアップを有効にしました。Amazon S3: Joker プラットフォームには、Joker のオファーを管理および報告するための管理パネルがあります。この管理インターフェイスをホストするため (基本的に Single Page Application (SPA) と AngularJS)、Amazon S3 の静的ウェブサイトホスティング機能を使用しました。すべてのロジックと機能は Lambda で実行されているメソッドによって提供されているため、管理インターフェイス用のサーバーは必要ありませんでした。

Amazon CloudWatch: 当社はこのサービスを使用して重要なアセットの使用量をモニタリングし、何かあった場合にアラートを受け取っています。プロダクションデータベースの CPU、接続カウント、重要な API レイテンシー、および関数のカウントと継続時間をモニタリングするためにカスタムダッシュボードを作成しました。Python コードで、CloudWatch の各内部メソッドの継続時間をログに記録し、パフォーマンスを追跡してボトルネックを発見します。

CloudWatch ダッシュボードを次に示します。

Amazon ElasticSearch: 開発段階中に、Amazon ES への Cloudwatch ログストリーミングがアイルランドリージョンで利用可能になりました。この機能を使用して、コードから生成するログの他のメトリックスをモニタリングするため、Kibana ダッシュボードを作成しました。Amazon ES がフランクフルトリージョンで利用可能になったらすぐに、再びこれを使用する予定です。

初期の結果
Joker システムは、国の小規模なリージョンに対して、パイロット運用として現在は実稼働状態になっています。次の図からわかるように、注文数の増加は前途有望です。当社は、サーバーレスアーキテクチャを利用することで、オペレーティングシステムと依存関係をインストール、管理する必要がなくなりました。Amazon API Gateway、AWS Lambda、Amazon S3、および Amazon RDS を使用することで、当社のアーキテクチャを可用性の高い環境で実行できます。マスタースレーブレプリケーション機能やサードパーティーのツールについて学習し、管理する必要がありません。サービスでより多くのリクエストを受け取ると、AWS Lambda がより多くの Lambda インスタンスを追加し、任意のスケールで実行されます。実稼働に移行する前のように、AWS サービスの機能を使用してサービスを別のリージョンにコピーすることができます。最後に、サーバーは一切実行していないので、サーバーレスアーキテクチャの費用のメリットを活用できます。Joker を通じて行われたオーダー数を次に示します。

次のステップ
このサービスが Delivery Hero Holding の 34 の関連会社すべてに拡大されることを願っています。サービスをグローバルに展開する際に、他の AWS リージョンにデプロイします。会社に最も近いリージョンを選択する予定です。費用を最適化するため、RDS インスタンス用のリザーブドインスタンスを購入します。また、内部メソッドの継続時間をモニタリングし、コードをリファクタリングおよび最適化して、Lambda 関数の実行時間を減らすことができます。当社はクラウドの将来は FaaS であると考えています。他の機能、サービス、関数が利用可能になったときにさらに試したいと思っています。AWS コミュニティヒーローとして、トルコの AWS ユーザーグループと Yemeksepeti の事例を共有することを楽しみにしています。みなさまのサーバーレスアーキテクチャの検証と利用のお手伝いができればと考えております。– Onur Salk