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
第169回 雲勉 AWS WAF 構築 RTA
iret
0
11
第168回 雲勉 JITNAの使い方とハマったポイントについて語る回
iret
0
34
第167回 雲勉 エージェント開発を加速する Agent Development Kit 入門
iret
1
38
第166回 雲勉 コードを読んで理解する AWS Amplify Gen2 Backend
iret
0
37
第165回 雲勉 Google Agentspace について
iret
0
31
第164回 雲勉 Agent Development Kit と MCP Toolbox for Databases で MCP 連携してみた
iret
1
67
第163回 雲勉 CircleCIで複数リポジトリ間のパイプラインを連携する
iret
1
35
第162回 雲勉 比較して学ぶ AWS Amplify Gen 2
iret
0
49
第161回 雲勉 Amazon Kinesis Data Streams と Amazon Data Firehose を使ってみよう
iret
0
50
Other Decks in Technology
See All in Technology
Ktor + Google Cloud Tasks/PubSub におけるOTel Messaging計装の実践
sansantech
PRO
1
280
分散トレーシングによる コネクティッドカーのデータ処理見える化の試み
thatsdone
0
220
OTel 公式ドキュメント翻訳 PJ から始めるコミュニティ活動/Community activities starting with the OTel official document translation project
msksgm
0
250
Webの技術とガジェットで那須の子ども達にワクワクを! / IoTLT_20250720
you
PRO
0
120
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
220
From Live Coding to Vibe Coding with Firebase Studio
firebasethailand
1
150
MCPに潜むセキュリティリスクを考えてみる
milix_m
1
740
Snowflake のアーキテクチャは本当に筋がよかったのか / Data Engineering Study #30
indigo13love
0
260
DatabricksのOLTPデータベース『Lakebase』に詳しくなろう!
inoutk
0
110
データエンジニアリング 4年前と変わったこと、 4年前と変わらないこと
tanakarian
2
360
生成AIによる情報システムへのインパクト
taka_aki
1
150
ecspressoの設計思想に至る道 / sekkeinight2025
fujiwara3
11
1.5k
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
35
6.8k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Statistics for Hackers
jakevdp
799
220k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Speed Design
sergeychernyshev
32
1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
We Have a Design System, Now What?
morganepeng
53
7.7k
Site-Speed That Sticks
csswizardry
10
720
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
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