大阪オフィスの林です。
re:Invent 2023 も気付けば終盤ですね！
「Amazon EBS」という身近なサービスで「300 - 上級」のワークショップがありましたのでどんな内容なのかの確認も含め参加してきました！
セッションタイトル
STG349 | Amazon EBS を使用してビジネス アプリケーションをデプロイするための包括的なガイド
STG349 | Comprehensive guide to deploying business applications with Amazon EBS
セッション概要
何百万ものユーザーが、パフォーマンス重視のエンタープライズ アプリケーションやデータベースを AWS 上で実行しています。
このワークショップでは、可用性、復元力、コストパフォーマンスを最適化するために、Amazon EC2 および Amazon EBS に高性能アプリケーションをデプロイする段階的なプロセスを学びます。
さまざまなワークロードに最適な Amazon EC2 インスタンス タイプと Amazon EBS ボリューム タイプを選択する方法を説明します。Elastic Volumes を使用したオンデマンド ストレージの柔軟性とパフォーマンスについて学びます。
Amazon CloudWatch メトリクスを使用して、Amazon EBS の運用パフォーマンスとリソースの最適化をモニタリングし改善します。
AWS Fault Injection Simulator を使用して、復元力と耐障害性を構築します。
ワークショップ前の雰囲気
だんだんこの独特の雰囲気にも慣れてきました！
ワークショップ前の講義
他のワークショップ同様にワークショップ前の講義がありました。
基本的なEBSの機能紹介から始まり、ユースケースに応じたボリュームタイプの解説などもあり改めて勉強になりました。（こうやってひと目で分かるように伝えてくれるスライド、、、好き。。
講義もそこそこにワークショップの内容説明に移ります。
ワークショップの概要はざっくり以下の通りです。
- EC2（EBS）にアプリケーションをデプロイし、CloudWatch を使用してボリュームを監視および最適化する
- Fault Injection Simulator を使用してリカバリ機能をテストする
- Compute Optimizer と Trusted Advisor を使用したコスト最適化戦略の方法を学ぶ
いざ、ワークショップ
ワークショップは7つのセクションに分かれて進めていくようです。
- 事前準備
- EBSデータ保護
- CloudWatch を使用した EBS のモニタリング
- EBS エラスティック ボリュームのチューニング
- Fault Injection Simulatorを使った疑似障害
- スナップショットからボリュームを復元
- EBSコストの最適化
1．事前準備
データベースをホストしているEC2（下図、Server01）にアタッチされているEBS ボリュームに書き込み負荷を掛けるためHammerDB というオープンソースのパッケージを使用して事前に準備されていたサンプルスクリプトを実行します。
後続の作業でスナップショットからリストアするため、今のデータベースの状態を確認します。
order_line | 14995559を記録しておきます。
productiondb=# select
productiondb-# table_schema,
productiondb-# table_name,
productiondb-# count_rows(table_schema, table_name)
productiondb-# from information_schema.tables
productiondb-# where
productiondb-# table_schema not in ('pg_catalog', 'information_schema')
productiondb-# and table_type='BASE TABLE'
productiondb-# order by 3 desc;
table_schema | table_name | count_rows
--------------+------------+------------
public | order_line | 14995559
public | stock | 5000000
public | customer | 1500000
public | history | 1500000
public | orders | 1500000
public | new_order | 450000
public | item | 100000
public | district | 500
public | warehouse | 50
(9 rows)事前準備はこれだけです。
2. EBSデータ保護
はじめに、EBSのスナップショットを作成します。 講義の中でも説明がありましたので、EBSスナップショットについて改めてまとめておきます。
- EBS スナップショットを使用してデータ保護を保護する
- スナップショットは EBS ボリュームのポイントインタイム バックアップであり、データは AWS が管理する S3 バケットにバックアップされる
- これにより、99.999999999% の耐久性を持つスナップショットが提供される
- 最初のスナップショットのみが完全なスナップショットになる
- 最初のスナップショット以降の後続のスナップショットはすべて増分となる
- つまり、前のスナップショットからの差分変更のみが含まれる
- これにより、スナップショットが非常に効率的になる
次に、高速スナップショット復元 (FSR)を有効にします。
FSRを使用して作成されたボリュームは、スナップショットからボリュームをリストアする際の I/O 操作のレイテンシーが無くなるため、プロビジョニングのパフォーマンスがすばやく提供されます。
3. CloudWatch を使用した EBS のモニタリング
このセクションでは、EBS ボリュームのパフォーマンスの視覚を行っていきます。
CloudFormation を使用して CloudWatch ダッシュボードをデプロイし、CloudWatch ダッシュボードに表示される EBS メトリクスを確認します。
事前準備で負荷を掛けたタイミングからグラフに変化があることが見て取れます。
4. EBS エラスティックボリュームのチューニング
エラスティックボリュームであれば、ボリュームサイズを増やしたり、ボリュームタイプを変更したり、IPOSやスループットなどのボリュームのパフォーマンスもチューニングでき、ボリュームのデタッチもインスタンスの再起動無しで可能です。
このセクションでは、EBSのIOPSとスループットを上げ、その後のCloudWatch メトリクスを確認するという作業を進めていきます。
EBSのIOPSとスループットを上げます。
再度、CloudWatch メトリクスを確認するとスループットを上げた分だけグラフも上昇しています。
5. Fault Injection Simulatorを使った疑似障害
AWS Fault Injection Simulator (AWS FIS) は、AWS ワークロードでフォールト挿入実験を実行できるマネージド サービスです。
このワークショップでは、AWS FIS を使用してターゲット EBS ボリュームの I/O 操作を一時停止し、そのボリュームの障害をシミュレートします。
AWS FIS を使用して実験を作成し、EBS ボリューム上の I/O を3分間停止させます。
I/O が一時停止および再開されたときにボリュームの CloudWatch メトリクスを確認します。
確認後、事前準備で実行していた書き込み負荷を掛けるスクリプトを停止しておきます。
6. スナップショットからボリュームを復元
事前に取得しておいた特定時点のスナップショットから EBS ボリュームを復元します。
スナップショットから作成されたボリュームは、バックグラウンドで遅延して読み込まれます。
これは、すべてのデータが Amazon S3 から EBS ボリュームに転送されるのを待たず、インスタンスが接続されたボリュームとそのすべてのデータへのアクセスを開始可能にするためです。
インスタンスがまだロードされていないデータにアクセスすると、ボリュームは要求されたデータを Amazon S3 からすぐにダウンロードし、バックグラウンドで残りのボリュームデータのロードを続けます。
なお、ボリュームのパフォーマンスは、すべてのブロックがダウンロードされてボリュームに書き込まれた後に達成されます。
運用環境での初期パフォーマンスの低下を回避するには、dd または fio ユーティリティを使用してボリューム上のすべてのブロックから読み取るか、
FTR を有効にして作成時に完全に初期化されたボリュームを作成することが推奨されています。
では、やっていきます。
スナップショット取得時の正常な状態へと戻していくため、スナップショットから EBS ボリュームを復元します。
EBS ボリュームをデタッチ/アタッチします。
データベースの機能を確認し、スナップショット取得前のorder_line | 14995559と同じであることを確認します。
productiondb=# select
productiondb-# table_schema,
productiondb-# table_name,
productiondb-# count_rows(table_schema, table_name)
productiondb-# from information_schema.tables
productiondb-# where
productiondb-# table_schema not in ('pg_catalog', 'information_schema')
productiondb-# and table_type='BASE TABLE'
productiondb-# order by 3 desc;
table_schema | table_name | count_rows
--------------+------------+------------
public | order_line | 14995559
public | stock | 5000000
public | customer | 1500000
public | history | 1500000
public | orders | 1500000
public | new_order | 450000
public | item | 100000
public | district | 500
public | warehouse | 50
(9 rows)7. EBSコストの最適化
コストのセクションは必要な情報がまだCost Exprolerに吸い上げられていない。といった類の理由で今回のワークショップではスキップでした。
本来であれば、Cost Exproler、Compute Optimizer、Trusted Advisorなんかを使いながらコスト分析をするそうです。
おわりに
周辺の機能を組み合わせて、障害をシミュレーションする感じのワークショップだったので思っていた以上に楽しかったという印象です。
今回、慣れ親しんだサービスのワークショップはあえて選択してなかったのですが、参加してみたら参加してみたで学びになることや発見も多く、良い機会になりました！
0
