Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
第152回 雲勉 シームレスなマルチリージョンへの移行と検討 ~Amazon EKSとAWS ...
Search
iret.kumoben
January 17, 2025
Technology
0
120
第152回 雲勉 シームレスなマルチリージョンへの移行と検討 ~Amazon EKSとAWS Global Acceleratorを使用した環境〜
下記、勉強会での資料です。
https://youtu.be/mGmG0NII8Fg
iret.kumoben
January 17, 2025
Tweet
Share
More Decks by iret.kumoben
See All by iret.kumoben
第173回 雲勉 ノーコードで生成 AI アプリを構築!Google Cloud AI Applications(旧 Vertex AI Agent Builder)入門
iret
0
13
第170回 雲勉 Lyria が切り拓く音楽制作の未来
iret
1
24
第169回 雲勉 AWS WAF 構築 RTA
iret
0
33
第168回 雲勉 JITNAの使い方とハマったポイントについて語る回
iret
0
35
第167回 雲勉 エージェント開発を加速する Agent Development Kit 入門
iret
1
43
第166回 雲勉 コードを読んで理解する AWS Amplify Gen2 Backend
iret
0
44
第165回 雲勉 Google Agentspace について
iret
0
45
第164回 雲勉 Agent Development Kit と MCP Toolbox for Databases で MCP 連携してみた
iret
1
93
第163回 雲勉 CircleCIで複数リポジトリ間のパイプラインを連携する
iret
1
39
Other Decks in Technology
See All in Technology
薬屋のひとりごとにみるトラブルシューティング
tomokusaba
0
370
[OCI Technical Deep Dive] OracleのAI戦略(2025年8月5日開催)
oracle4engineer
PRO
1
200
OPENLOGI Company Profile for engineer
hr01
1
38k
MCP認可の現在地と自律型エージェント対応に向けた課題 / MCP Authorization Today and Challenges to Support Autonomous Agents
yokawasa
5
2.4k
Amazon Inspector コードセキュリティで手軽に実現するシフトレフト
maimyyym
0
120
AIに頼りすぎない新人育成術
cuebic9bic
3
320
マルチプロダクト×マルチテナントを支えるモジュラモノリスを中心としたアソビューのアーキテクチャ
disc99
1
590
[kickflow]20250319_少人数チームでのAutify活用
otouhujej
0
110
テストを実行してSorbetのsigを書こう!
sansantech
PRO
1
120
PL/pgSQLの基本と使い所
tameguro
2
220
Telemetry APIから学ぶGoogle Cloud ObservabilityとOpenTelemetryの現在 / getting-started-telemetry-api-with-google-cloud
k6s4i53rx
0
160
20250807_Kiroと私の反省会
riz3f7
0
240
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Language of Interfaces
destraynor
158
25k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Balancing Empowerment & Direction
lara
2
550
Agile that works and the tools we love
rasmusluckow
329
21k
Producing Creativity
orderedlist
PRO
347
40k
The Pragmatic Product Professional
lauravandoore
36
6.8k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
880
For a Future-Friendly Web
brad_frost
179
9.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
Embracing the Ebb and Flow
colly
86
4.8k
Transcript
第152回 雲勉 シームレスなマルチリージョンへの移行と検討 ~Amazon EKSとAWS Global Acceleratorを使用した環境〜
講師自己紹介 2 ◼ 名前: 茅根 涼平 • (所属)クラウドインテグレーション事業部SREセクション(グループリーダー) • (アイレット歴)7年目
• (担当)コンテナ、エンドユーザーコンピューティング、ネットワーキングとコンテンツ配信 ご質問は YouTubeのコメント欄で受け付けております。 後日回答させていただきます! AWS Well-Architected Lead JAWS-UG 茨城
アジェンダ 3 ◼ 話すこと 1. AWS Global Acceleratorを使った移行 2. コスト試算(AWS利用料)
3. マルチリージョン化によって得られるメリット 4. まとめ ◼ 話さないこと ・CI/CDを使用したマルチクラスター管理方法 ・データベースやストレージ管理方法
1.シームレスなマルチリージョンへの移行 4
1.シームレスなマルチリージョンへの移行 5 ◼ 構成図 AWS Global Accelerator と Amazon Route
53 を使用して、 2 つの AWS リージョンで稼働する環境でトラフィック分散します ※今回はEKSを使用して検証します
6 ◼ AWS Global Acceleratorとは? AWS Global Accelerator は、世界中の顧客に提供するアプリケーションの可用性と パフォーマンスを改善するネットワーキングサービスです。
1.シームレスなマルチリージョンへの移行
7 ◼ AWS Global Acceleratorの特徴 AWS グローバルネットワークを利用しアプリケーションのグローバルな 可用性とパフォーマンスを向上します。 ・固定エントリポイントとして機能する静的 IP
アドレスがある ・地理情報に基づいてルーティング可能です ・正常に動作しているエンドポイントにルーティングします ・特定リージョンのトラフィックの割合を調整できます ・DDoS攻撃からの保護機能があります 1.シームレスなマルチリージョンへの移行
8 ◼ EKSとは? AWS上でKubernetesクラスタを簡単に実行、管理できるマネージドサービスで、 高い可用性とセキュリティを備え、AWSの各種サービスと容易に統合できます。 フルマネージド コントロールプレーンの管理を AWS が担うため運用負荷を軽減できます。 1.シームレスなマルチリージョンへの移行
9 ◼ 使用するツール • AWS CLI version 2 • eksctl
• kubectl • helm • ドメインおよび Route 53 ホストゾーン 1.シームレスなマルチリージョンへの移行
10 ◼ 環境変数を設定する 1.シームレスなマルチリージョンへの移行
11 ◼ EKSクラスターの作成 eksctl を使用して 2 つの異なるリージョンに 2 つのEKSクラスターを作成します。 任意でノード数やノードのインスタンスタイプを指定してください。
1.シームレスなマルチリージョンへの移行
12 ◼ AWS Load Balancer Controller をインストールする Kubernetes の Ingress
に Application Load Balancer を使用できるように AWS Load Balancer Controller をそれぞれの EKS クラスターにインストールします。 参考 https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/installation/ 1.シームレスなマルチリージョンへの移行 クラスター用に OIDC プロバイダーを作成
13 参考 https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/installation/ 1.シームレスなマルチリージョンへの移行 AWS Load Balancer Controller に使用する IAM
ポリシードキュメントを ダウンロード、 IAM ポリシーを作成 IAM ロールと Kubernetes の Service Account を作成
14 参考 https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/installation/ 1.シームレスなマルチリージョンへの移行 AWS Load Balancer Controller に使用する IAM
ポリシードキュメントを ダウンロード、 IAM ポリシーを作成する コントローラーをインストールする ※コンテキストの指定を忘れずにする
15 ◼ アプリケーションをデプロイする 1.シームレスなマルチリージョンへの移行 サンプルアプリケーションをデプロイします。 今回はAWS公式ドキュメントにあるクイックスタートをもとに設定します。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/quickstart.html
16 ◼ Global Accelerator を設定する アクセラレータ名:任意 その他の項目:スキップ 1.シームレスなマルチリージョンへの移行
17 ◼ Global Accelerator を設定する 検証のためTCP80で設定する エンドポイントを東京と大阪で設定する 1.シームレスなマルチリージョンへの移行 トラフィックダイヤル さまざまなリージョンにわたり、
新しいリリースのパフォーマンス テストやブルー/グリーンデプロイ などを簡単に実行できます。
18 ◼ Global Accelerator を設定する 作成したALBをそれぞれ選択する 1.シームレスなマルチリージョンへの移行
19 ◼ Route 53 を設定する 作成したGlobal Acceleratorを選択し、DNSレコードを作成する 1.シームレスなマルチリージョンへの移行
20 ◼ フェイルオーバーをテストする EKS クラスターで実行されている Pod を意図的に終了します。 1.シームレスなマルチリージョンへの移行
21 ◼ フェイルオーバーをテストする プライマリー環境(東京)で実行しているPodを終了すると、以下のように5xx系エラーになります。 Global Accelerator のヘルスチェックが失敗してからサービス用のドメインにアクセスすると、 正常にアクセスできることがわかります。 1.シームレスなマルチリージョンへの移行
22 ◼ Global Accelerator のヘルスチェック 1.シームレスなマルチリージョンへの移行
23 ◼ 異常なエンドポイントに対するフェイルオーバーの仕組 エンドポイントグループに重みが 0 より大きい正常なエンドポイントがない場合 Global Accelerator は別のエンドポイントグループの重みが 0
より大きい正常なエンドポイン トにフェイルオーバーしようとします。 このフェイルオーバーにおいて Global Accelerator はトラフィックダイヤルの設定を無視します。 プライマリー環境(東京)の Deployment をスケールアップすると、数分後に Global Accelerator はすべてのリクエストをプライマリー環境(東京)に流れます。 1.シームレスなマルチリージョンへの移行
24 ◼ Global AcceleratorとRoute 53の比較 Route 53でトラフィックフローを管理するのと比較すると、AWS Global Acceleratorの方が容易です。 1.シームレスなマルチリージョンへの移行
Global Accelerator レイテンシーや地理的なルーティングなど、 独自にきめ細かいルールを決めなくていい場合、 Global Acceleratorに任せることができます。 管理者は主に ・エンドポイントの指定 ・トラフィックダイアルの調整 ・加重の調整 の3つ程度の管理をすることになります。 Route 53 大規模で複雑なDNS管理をするには、 多くの知識と運用コストがかかります。 管理者は主に トラフィックフロー機能を使用して、 ・トラフィックポリシー ・ポリシーレコード を管理しますが、トラフィックポリシーを作成す るにはDNSの知識が必要です。
25 ◼ Global AcceleratorとRoute 53の比較 AWS Global Accelerator を使用すると、クライアントデバイスの IPアドレスキャッシュに依存する必要がなくなります。
そのため、DNSのキャッシュに悩まされることなくサービス提供ができるようになります。 Global Accelerator Route 53 AWSのEdge Locationによる負荷分散 DNSベースで分散 ヘルスチェックによるFailover ヘルスチェックによるFailover 固定IPによるアクセス ルーティングポリシーに基づく AWSバックボーンネットワーク による高速化 1.シームレスなマルチリージョンへの移行
2. コスト試算(AWS利用料) 26
2.コスト試算(AWS利用料) 27 ◼ EKSクラスターの料金 1時間あたり、0.10USD 1日あたり、2.40USD 1ヶ月あたり、72.0USD
2.コスト試算(AWS利用料) 28 ◼ AWS Global Acceleratorの料金 AWS Global Accelerator では、プロビジョニングされたアクセラレーターや、
アクセラレーターを流れる主要な方向のトラフィック量に応じて課金されます。 参考 https://aws.amazon.com/jp/global-accelerator/pricing/ 月額128USD
2.コスト試算(AWS利用料) 29 ◼ (例)総額の概算コスト EKSおよびGlobal Acceleratorの使用 72USD+128USD=200USD 年間: 2,400USD(378,444円) 換算($1=157.69)
アプリケーションに最適なソリューションは、特定のニーズによって異なります。 パフォーマンス重視 Global Accelerator コスト重視 DNS ベースのソリューション
2.コスト試算(AWS利用料) 30 ◼ (おまけ)パイロットライト戦略で災害対策 クラウド構成と料金試算例 https://aws.amazon.com/jp/cdp/dr/ 月額 (右図)1,187.86USD (P.27)+200USD =合計1,459.86USD
年間 17,518.32USD 2,762,464円~
3.マルチリージョン化によって 得られるメリット 31
32 ◼ リージョン障害発生時 • 判断 • 新規クラスタ構築 • アプリケーションデプロイ •
動作確認 • DNS切り替え ・目標復旧時間 (RTO)が達成できない ・SLA/SLOに影響 ・ユーザー影響(不満・クレーム) ・エンジニアの精神的負荷が大きい シングルクラスターの場合 復旧に2時間以上かかる可能性がある 3.マルチリージョン化によって得られるメリット
33 AWSの仕様上、クラスターを前のバージョンに戻すことはできない ◼ EKSアップデートにリスクがある 3.マルチリージョン化によって得られるメリット ステータス上は問題ないけどサービス影響が出た ↓ 対策前進に時間がかかりそう ↓ 作業前の状態と同じにする
• EKSクラスター/ノードの作成 • Helmfile(k8s マニフェスト)の作成 • 動作確認
34 • ローリングアップデート ソフトウェアの更新、入れ替えの方法の一つで、稼働中のシステムに直接ソフトウェアの更新や入れ替えを行うこと • Blue/Greenデプロイ 新旧の環境を用意して接続先を切り替えて公開する • カナリアリリース 一部のユーザに対して徐々に公開していく※Blue/Greenの一種
方法 工数 安全性 ローリングアップデート ワンクリックだから簡単 クラスターの切り戻し不可 Blue/Greenデプロイ スタンバイ環境があるので、 すぐに切り替えできる 切り戻し可能 カナリアリリース スタンバイ環境があるので、 すぐに切り替えできる 切り戻し可能 3.マルチリージョン化によって得られるメリット
3.マルチリージョン化によって得られるメリット 35 パフォーマンス効率 チームの編成 ワークロードの設計 ワークロードの大規模な運用 チームの学習、共有、改善 回復力(障害を軽減する) 可用性 DR対応
ネットワーキングとコンテンツ配信 プロセスと文化 参考 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/operational-excellence.html https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/definitions.html https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/performance-efficiency-pillar/definition.html ◼ AWS Well-Architectedから考える 信頼性 運用上の優秀性 AWSにおける設計のベストプラクティスの理解度が深まる
4.まとめ 36
4.まとめ 37 ◼ リージョン障害時の復旧が短縮、落ち着いて対応できる EKSアップデートは定期的に実施するため、副次的にBCP訓練がしやすい ◼ EKSアップデートが安心して実施できる 万が一失敗しても、ダウンタイムを最小限にできる ◼ シームレスなマルチリージョン移行
Global Acceleratorを使うことで実現することができる
ご視聴ありがとうございました 38