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
第87回 雲勉【オンライン:初心者向け】AWSの構築・運用でインフラエンジニアが意図せずハマっ...
Search
l_tanno
October 28, 2022
Technology
0
100
第87回 雲勉【オンライン:初心者向け】AWSの構築・運用でインフラエンジニアが意図せずハマった事象と対策をご紹介
l_tanno
October 28, 2022
Tweet
Share
More Decks by l_tanno
See All by l_tanno
第100回 雲勉【オンライン:中級者向け】EKSのアップデートを安全に行う
l_tanno
1
71
第97回 雲勉【オンライン:初心者向け】Google Cloudの基礎から学んで、Compute Engineを構築できるようになろう
l_tanno
0
110
第94回 雲勉【オンライン:初心者向け】第2回24/365運用業務を支えるMSP〜クラウド運用業務に必要なもの〜
l_tanno
0
53
第91回 雲勉【オンライン:初心者向け】サーバレスでブログサイト開設〜Amplify Studio〜
l_tanno
1
110
第89回 雲勉【オンライン:初心者向け】実践!SLI/SLO with New Relic!
l_tanno
0
150
第88回 雲勉【オンライン:中級者向け】DeepSecurity(C1WS)機能紹介 _現場から出た_にもこたえてみた
l_tanno
0
420
第85回 雲勉【オンライン:初心者向け】EKSを触ってみよう 〜Kubernetes知らない人大集合〜
l_tanno
0
140
Other Decks in Technology
See All in Technology
AI コードレビューが面倒すぎるのでテスト駆動開発で解決しようとして読んだら、根本的に俺の勘違いだった
mutsumix
0
160
クマ×共生 HACKATHON - 熊対策を『特別な行動」から「生活の一部」に -
pharaohkj
0
290
相互運用可能な学修歴クレデンシャルに向けた標準技術と国際動向
fujie
0
200
データ基盤の管理者からGoogle Cloud全体の管理者になっていた話
zozotech
PRO
0
330
20250807_Kiroと私の反省会
riz3f7
0
130
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
1.9k
AI時代の経営、Bet AI Vision #BetAIDay
layerx
PRO
1
1.7k
AIに目を奪われすぎて、周りの困っている人間が見えなくなっていませんか?
cap120
1
430
LLMをツールからプラットフォームへ〜Ai Workforceの戦略〜 #BetAIDay
layerx
PRO
1
840
【OptimizationNight】数理最適化のラストワンマイルとしてのUIUX
brainpadpr
0
160
大規模イベントに向けた ABEMA アーキテクチャの遍歴 ~ Platform Strategy 詳細解説 ~
nagapad
0
190
【Λ(らむだ)】最近のアプデ情報 / RPALT20250729
lambda
0
230
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Being A Developer After 40
akosma
90
590k
A designer walks into a library…
pauljervisheath
207
24k
How to Ace a Technical Interview
jacobian
278
23k
The Pragmatic Product Professional
lauravandoore
36
6.8k
[RailsConf 2023] Rails as a piece of cake
palkan
56
5.7k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
21
1.4k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
420
Into the Great Unknown - MozCon
thekraken
40
2k
Git: the NoSQL Database
bkeepers
PRO
431
65k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Transcript
第87回 雲勉【オンライン︓初⼼者向け】 AWSの構築・運⽤で インフラエンジニアが意図せずハマった事象と対策をご紹介 2022/10/27
0.講師⾃⼰紹介 2 n 荒尾 将吾 n 所属 クラウドインテグレーション事業部 構築第六セクション 構築第三グループ
様々なお客様のご要望に応じてAWSの設計/構築/運⽤を⾏っています。 n 経歴 ~2015年 営業やったり、カフェでバイトしたり。 2015年~ インフラエンジニアとしてキャリアをスタート。 2022年4⽉~ アイレットに⼊社。
アジェンダ 3 0.⾃⼰紹介 1.ハマったときの基本的な調査⽅法(19:05~19:10) 2.ハマった事例と対策3選(19:10~19:50) 3.まとめ 4.質疑応答(19:50~20:00)
0. ハマるとは 4
0. ハマるとは 5 ⽳などのくぼみに落ちる、条件にぴったり合致する、夢中になる、といった意味の表現。 (出典: 実⽤⽇本語表現辞典)
0. ハマるとは 6 今回の場合 意図しないトラブルに遭遇した という意味
1. AWSサービスで意図せずハマったときの基本的な調査⽅法 7
1. ハマったときの原則 8 n 確認ポイント
1. ハマったときの原則 9 n 確認ポイント
1. ハマったときの原則 10 n ログの例: マネージドコンソールに表⽰されるメッセージ • 操作が完了しなかった理由が表⽰される
1. ハマったときの原則 11 n ログの重要性 • 事象の発⽣している原因や理由をログが⽰してくれる • インターネットで検索するためのキーワードはログに含まれていることが多い •
AWSサポートに問い合わせするにもログが必要(技術的な問い合わせは別途契約が必要) ログ出⼒の設定⽅法 ログの読み⽅ を知っていることが⼤事
2.ハマった事例と対策3選 12 n AWSの主なサービスのログ ログの種類 概要 マネージドコンソールに 表⽰されるメッセージ マネージドコンソールの操作結果を表⽰ CloudWatch
リソースをリアルタイムでモニタリング CloudTrail API操作のログ VPCフローログ ENIやVPC、Transit Gatewayの通信ログを収集 アクセスログ ELBやCloudFront、S3のアクセスログなど 各サービスのログ SSMエージェントのログ、RDSのイベントログなど
2.ハマった事例と対策3選 13 n AWSの主なサービスのログ ログの種類 概要 マネージドコンソールに 表⽰されるメッセージ マネージドコンソールの操作結果を表⽰ CloudWatch
リソースをリアルタイムでモニタリング CloudTrail API操作のログ VPCフローログ ENIやVPC、Transit Gatewayの通信ログを収集 アクセスログ ELBやCloudFront、S3のアクセスログなど 各サービスのログ SSMエージェントのログ、RDSのイベントログなど
2. 経験豊富な構築・運⽤を担当するインフラエンジニアが AWSサービスで意図せずハマった事例と対策 3選 14
2.ハマった事例と対策3選 15 2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 2-2. オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 2-3. オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 16
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 17 n 概要 ジョブサーバでAWS CLIを実⾏しEC2インスタンスを定期停⽌/起動する構成 複数稼働するEC2インスタンスの⼀部で停⽌後起動しない事象が発⽣した
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 18 n 原因 1. AWS Key Management
Service(KMS)で暗号化されたEBSがEC2にアタッチされていた。 2. AWS CLIを実⾏するIAMロールにKMSに関するポリシーが不⾜していた。 KMSのポリシーがアタッチされていないIAMアカウントで 実際に以下のインスタンスに対してAWS CLIのstart-instancesをやってみます。 インスタンス名 インスタンスID 暗号化 kumoben i-0e3329c2fda3e54d2 なし kumoben-encrypted i-01bfe8fdcdc29d490 あり
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 19 n AWSの主なサービスのログ ログの種類 概要 マネージドコンソールに 表⽰されるメッセージ
マネージドコンソールの操作結果を表⽰ CloudWatch リソースをリアルタイムでモニタリング CloudTrail API操作のログ VPCフローログ ENIやVPC、Transit Gatewayの通信ログを収集 アクセスログ ELBやCloudFront、S3のアクセスログなど 各サービスのログ SSMエージェントのログ、RDSのイベントログなど
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 20 n CloudTrail • ユーザー、ロール、または AWS のサービスによって実⾏されたアクションは
CloudTrail にイベントとして記録 • つまりはAPI操作のログ
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 21 n 調査⽅法 正常に起動できるEC2インスタンスと設定値⽐較 AWS CLIの実⾏内容を確認するためにCloudTrailでAPI処理結果を確認
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 22 n 解決策 以下のKMSを許可するIAMポリシーを作成しIAMロールにアタッチ
2-1. AWS CLIでEC2インスタンスを停⽌できるが起動できない 23 n 原因特定まで時間がかかった理由 • AWS CLIで停⽌はできたため、IAMの権限は問題ないという思い込みがあった。 •
AWS CLIのstart-instances実⾏結果にエラーは表⽰されなかったため、AWS CLIではなく EC2インスタンスにOSレベルの問題があると考えた。
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 24
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 25 n 概要 オンプレミス環境からAWS Application Migration Service(MGN)で 移⾏したEC2インスタンスで性能測定した際、オンプレミス環境に⽐べEC2インスタンスでの 処理が2~3倍かかった。2回⽬以降の性能測定では多少の性能改善が⾒られた。
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 26 n 原因 1. EBSのスループットとIOPSがアプリケーションの要件に達していなかった。 2. S3からEBSへのデータ転送がボトルネックになっていた。
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 27 n AWSの主なサービスのログ ログの種類 概要 マネージドコンソールに 表⽰されるメッセージ マネージドコンソールの操作結果を表⽰ CloudWatch
リソースをリアルタイムでモニタリング CloudTrail API操作のログ VPCフローログ ENIやVPC、Transit Gatewayの通信ログを収集 アクセスログ ELBやCloudFront、S3のアクセスログなど 各サービスのログ SSMエージェントのログ、RDSのイベントログなど
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 28 n CloudWatch • AWSリソースとアプリケーションをリアルタイムでモニタリング • メトリクスを収集 • カスタムメトリクスをCloudWatchに対して発⾏することも可能
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 29 n 調査⽅法 CPUやメモリのスペックは移⾏後のほうが優っていることからEBSの性能を主に調査 EBSのスループットとIOPSがどの程度利⽤されているかCloudWatchのメトリクスで経過観察
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 30 n 解決策 1. EBSはgp3で作成していたため、スループットとIOPSの設定値(※1)を変更 2. EBS 帯域幅(※2) のスペックが⾼いインスタンスタイプに変更
3. 初回のファイルアクセスが遅い事象はAmazon EBS Fast Snapshot Restore(FSR)で対応 ※2 ※1
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 31 n インスタンスタイプが⼤事 • CPUやメモリに注視して、EBSのスペックは意外と⾒落としがち m6i系 m5系
2-2.オンプレミス環境よりも移⾏したEC2インスタンスの動作が遅い 32 n Amazon EBS Fast Snapshot Restore(FSR) • FSR実⾏後のスナップショットからボリューム作成することで
初回のファイルアクセス時からEBSのスペック通りの性能がでる。 • スナップショット単位でAZ毎にFSRを有効化する。 • FSRの有効が完了するまでスナップショットサイズによって時間が異なる(1TB : 1時間)。
2-3.オンプレミス環境に対してEC2インスタンスから 通信ができたり、できなかったり 33
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 34 n 概要 以下構成でオンプレミスの⼀部サーバとEC2インスタンスが通信が不安定になる事象が発⽣
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 35 n 原因 複数のTransit Gateway Attachmentがある場合、AZ-aへの通信もAZ-cを経由する場合があ る仕様だった。しかし、AZ間で通信しないようにNetwork ACLで制限をしていた。
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 36 n AWSの主なサービスのログ ログの種類 概要 マネージドコンソールに 表⽰されるメッセージ マネージドコンソールの操作結果を表⽰ CloudWatch
リソースをリアルタイムでモニタリング CloudTrail API操作のログ VPCフローログ ENIやVPC、Transit Gatewayの通信ログを収集 アクセスログ ELBやCloudFront、S3のアクセスログなど 各サービスのログ SSMエージェントのログ、RDSのイベントログなど
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 37 n VPCフローログ • VPC のネットワークインターフェイスの間で⾏き来する IP トラフィックに関する情報を 参照できる機能
• 他のサービスと異なり事前に設定が必要
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 38 n VPCフローログの設定⽅法 • IAMポリシー作成 • IAMロール作成 • CloudWatchロググループ作成
• VPCフローログ作成
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 39 n VPCフローログの設定⽅法 • 以下のIAMポリシー作成
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 40 n VPCフローログの設定⽅法 • IAMロール作成 作成したIAMポリシーをアタッチ VPCフローログと信頼関係を設定
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 41 n VPCフローログの設定⽅法 • CloudWatchロググループ作成
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 42 n VPCフローログの設定⽅法 • VPCフローログ作成 フィルタ: すべて 最⼤集約間隔: 1分間
送信先: CloudWatch Logs 送信先ロググループ: 作成したロググループ IAMロール: 作成したIAMロール
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 43 n VPCフローログ • 送信元 送信先 送信元ポート 送信先ポート の順番で記載
• ACCEPT: 通信を許可 REJECT: 通信を拒否
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 44 n 解決策 n 調査⽅法 VPCフローログで通信の到達箇所を切り分け AWS公式ドキュメントを参照するが同様の事例を⾒つけることができず AWSサポートに問い合わせを実施 Transit
Gateway Attachmentの公開されていない仕様によりAZ-aへの通信もAZ-cを経由する 場合があることが判明 Network ACLでサブネット単位でNW制限するのではなく、Security GroupでENI単位で 通信制限するように変更することで回避
2-3.オンプレミス環境に対してEC2インスタンスから通信ができたり、できなかったり 45 n 原因特定まで時間がかかった理由 • Direct Connect、Transit Gateway、Network ACL、Security Group、
Route Table、EC2インスタンス、オンプレミスのサーバ等切り分け箇所が多かった。 n Network ACLの利⽤はおすすめしない • 複数のインフラエンジニアにハマった事例を聞いたところNetwork ACLに起因するものが いくつかあった。 • 意図しない通信遮断に繋がることが多くあり、切り分け箇所の検討が付けにくいことが 主な理由だった。
3.まとめ 46 ハマった経験がAWSサービスやインフラの知識をより深めると考えています。 改めてアイレットのインフラエンジニア達に事例を聞くことで実感しました。 ハマることは避けられないことなので予め調査⼿順を知っていることが 解決への道標になると思います。
4. 質疑応答 47