Amazon Web Services ブログ
株式会社ギフティ様「giftee Reward Suite」における Amazon EKS Auto Mode の導入事例のご紹介
このブログ記事は、株式会社ギフティ様が執筆し、Amazon Web Services Japan が監修しています。
はじめに
株式会社ギフティ (以下、ギフティ) は「eギフトを軸として、人、企業、街の間に、さまざまな縁を育むサービスを提供する」をビジョンに掲げ、カジュアルギフトサービス「giftee」や、法人・自治体向けにeギフトを活用したソリューションを提供する「giftee for Business」などを展開しています。
本稿では、弊社の「giftee for Business」のソリューションのうちの一つであり、2025年4月1日より提供を開始したキャンペーン基盤「giftee Reward Suite」のインフラ構築事例を紹介いたします。giftee Reward Suite は、企業の会員サービスと連携し、既存会員向けの効果的なキャンペーン施策やリワードプログラムの実装を継続して実現するための SaaS です。ユーザー認証から条件判定、抽選、ギフト配布までを一括で提供することで、企業が手軽にキャンペーンを実施できます。
giftee Reward Suite では、主に Amazon Elastic Kubernetes Service (以下、EKS) クラスタの運用管理がよりシンプルになる点に魅力を感じて、Amazon EKS Auto Mode (以下、EKS Auto Mode) を採用しています。EKS Auto Mode は2024年12月の AWS re:Invent において一般提供が開始されました。これは、Kubernetes クラスタのコンピューティング、ストレージ、およびネットワーキングの管理を自動化する新機能です。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、Kubernetes の実行や管理を簡素化することができます。クラスタ管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進により注力することが可能です。本稿では、「giftee for Business」における EKS Auto Mode の導入に至った経緯、採用したアーキテクチャ、導入効果、そして今後の展望についてご説明します。
プロジェクトの概要
本プロジェクトの開発は2024年1月頃にスタートし、2025年4月1日に日本生命保険相互会社をクライアントとしてサービスインを迎えることが決定していました。開発体制としては、フロントエンド主担当1名、バックエンド主担当2名、そしてインフラ担当1名（筆者）の計4名で開発を進めました。
プロジェクト期間は長く見えるかもしれませんが、法人向け SaaS システムとしての要件定義や設計をゼロベースで検討する必要があるため、インフラ構築にかけられる実質的な期間は限られていました。このため、短期間での効率的な構築が求められる状況でした。
EKS Auto Mode を採用した経緯
アーキテクチャとしては、マイクロサービス的な構想があることや、インフラ側でも複雑な要件が発生する可能性が高い状況であったので Kubernetes の採用も積極的に視野に入れて検討していました。開発当初は EKS on EC2 のマネージドノードで構築を進めていましたが、プロジェクト体制や兼務の問題があり、その運用負荷の高さが大きな課題でした。
そうした最中、2024年12月に EKS Auto Mode が発表され、アドオン等の AWS マネージドな領域が大きく広がり、EKS クラスタの運用管理がよりシンプルになる点に魅力を感じ、すぐに検証を開始しました。その後、採用を決定し2025年4月より本番環境でサービス稼働しています。
採用する上で大変だった点については後述しますが、今回の対象のワークロードは一般的な Web サーバー等のステートレスの構成が多く、EKS Auto Mode や Karpenter などの採用の際に注意が必要な長時間実行されるバッチ処理やステートフルなリソースも少ない構成でした。これが短期間での検証から採用に踏み切れた決め手のうちの一つと考えています。
なお、補足しておくと、EKS Auto Mode は長期実行のワークロードでも利用可能です。その場合の注意点や設定については、AWS ブログ「Amazon EKS Auto Mode のノード自動更新を Deep Dive する ~ 長期実行ワークロードを正しく取り扱う」が大変参考になります。
アーキテクチャ概要
特徴として、EKS Auto Mode のデータプレーン側の EC2 ノードは、高可用性のため 3AZ に冗長化されています。また本記事に直接関連しない箇所については、一部表記を省略しております。
図 1 giftee Reward Suite アーキテクチャ概略図
導入の効果
EKS Auto Mode の導入により、運用負荷が大幅に軽減されたのが最大のメリットであると感じています。具体的な効果は以下の3点です。
- クラスタ管理の簡素化：従来、EKS クラスタでは、AWS Load Balancer Controller や Kube proxy などの各種アドオンを自分たちで管理する必要がありました。EKS Auto Mode はこれらを AWS の責任範囲で自動的に管理してくれるため、バージョンアップといった運用タスクの負荷が軽減されました。
- ノード管理の効率化：開発当初は、EKS Managed ノードで Auto Scaling Group を利用して EC2 インスタンスのノードを管理していました。EKS Auto Mode では Karpenter をベースとしたクラスターオートスケーラーを含めて AWS の責任で管理されるため、自身で管理する必要がない点もメリットだと感じています。
- セキュリティ：EKS Auto Mode のノードでは、Bottlerocket と呼ばれるコンテナの実行に最適化された OS が利用され、セキュリティアップデートやパッチなどが AWS の責任で自動的に適用されることにより、セキュリティの安全性が確保されています。また、ノードの最大存続期間が21日に設定されており、自動的に新しいノードに置き換えられるため、セキュリティのベストプラクティスである定期的なノードの定期的な入れ替えが運用負荷なしに実現できています。
導入時の検討と課題
EKS Auto Mode は、従来の EKS に比べて AWS マネージドな領域が広がり、ユーザの運用がシンプルになる一方で、ユーザー側で設定できる範囲は狭まるというトレードオフがあると言えます。このため、導入にあたっては下記の事項について検討しましたが、今回のワークロード特性上、結果的に大きな制約とはなりませんでした。
- ノードの自動更新：EKS Auto Mode では、セキュリティの観点から最大21日ごとにノードが自動的に置き換えられます。これは、ホストサーバーにデータを保存するようなステートフルなワークロードや、長時間実行されるバッチ処理などがある場合は検討すべきポイントになります。ただ今回のワークロードは、データベースとして RDS や Valkey などのサービスを活用し、アプリケーション自体はステートレスな設計にしていました。また、バッチ処理もいくつか存在するものの、短時間で処理が終了するものであり、かつ冪等性も考慮していたため、制約にはなりませんでした。
- カスタム AMI の利用制限：EKS Auto Mode ではカスタム AMI を持ち込むことができません。これも、特定のソフトウェアをホストサーバーに事前にインストールしておく必要があるようなケースでは課題となり得ますが、今回のアプリケーションはホストサーバーに依存しない設計になっていたため、この点も制約とはなりませんでした。
- Security Group per Pod (SGPP) の非サポート：EKS Auto Mode では、Pod 単位でセキュリティグループを付与する Security Group per Pod (SGPP) が現時点ではサポートされていません。しかし、今回のアプリケーションで、Pod 単位でセキュリティ分離を行うモチベーションは強くありませんでした。また、将来的に特定のアプリケーションからのみ、ある AWS サービスへのアクセスを許可する要件が発生しても、NodeClass を利用して NodePool ごとに異なる Security Group を適用することで、一定のセキュリティ分離は達成できると見込んでいたため、大きな制約とは判断しませんでした。とはいえ、他アプリケーションでも EKS Auto Mode を利用することを想定すれば、pod レベルで Security Group が付与できる方がより良いと考えているため、今後 SGPP 相当の機能がリリースされることを期待しています。
一方で、Karpenter や EC2 ノードの管理等、AWS がマネージドで提供する機能の挙動を理解する必要があるという点は大変だったかもしれません。上記で述べた通り、EKS Auto Mode では今までユーザーが担う必要があった部分も AWS の責務範囲になっていますが、これらの機能が AWS マネージドになったからといって、もちろんその挙動を理解しなくても良いわけではなく、同様に理解する必要があります。
今回、キャッチアップに苦労した部分もありましたが、EKS Auto Mode のワークショップやコミュニティ勉強会の中で、AWS のプロフェッショナルの方々や、EKS を運用している事業会社のコミュニティメンバーとのディスカッションを通じて、理解を深めることができたと感じています。
今後の展望
「giftee Reward Suite 」を、今後より多くのお客様にご利用いただくための機能開発と、サービスの安定運用に引き続き注力していきます。
特にインフラ面では Karpenter の設定最適化を進めることでインフラコストの効率化をはかりたいと考えています。具体的には、スポットインスタンスの活用等を行う予定です。
まとめ
本稿では、「giftee Reward Suite」 における Amazon EKS Auto Mode の導入事例をご紹介いたしました。
EKS Auto Mode を採用することで、Kubernetes の優れたアーキテクチャを活用しつつ、クラスターの運用管理をシンプルにすることができました。Kubernetes の採用をご検討されており、運用負荷に懸念をお持ちの方々にとって、本事例が参考になれば幸いです。