Amazon EC2 大規模インフラで起きうる障害と対応【DeNA TechCon 2022】

2021/4 末のクラウド移行後、私の担当しているインフラでは約 2,000 のインスタンスを運用しています。サーバの台数が多いということもあり、日々運用を行なっていく上で多種多様な問題に直面します。これまであたったことがない問題に直面し対応することもあり、我々インフラエンジニアは「なぜこの問題が起きたのか」「どのように対応すればいいのか」など都度考え対応する必要があります。そうして初めて直面した問題に対しても適切な対応が行われることで、大規模インフラにおける安定したサーバ運用が成り立っています。

本セッションでは、大規模インフラを運用していく上でクラウド移行したからこそ生じた問題を紹介します。この問題は CPU や MEMORY など目にみえる状態は異常ないが、サーバへのコネクションが新規に接続できなくなるといった問題であり、原因が大変気付きにくいものでした。また、この問題に対してどのような対応を施策したのか、対応に至るまでのプロセスを含めお伝えします。

資料内でのリンク集：
p12, https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/security-group-connection-tracking.html

◆ You Tube
https://youtu.be/dWzI55iqNTk

◆ You Tube チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2022 公式サイト
https://techcon2022.dena.dev/spring/

Transcript

1. Amazon EC2 大規模インフラで起きうる障害と対応 橋本 將太 1
2. 自己紹介 : 橋本 將太 • 2019年 新卒入社 • ゲーム・オートモーティブ事業のインフラの運用 • 実績 ◦ クラウド移行 ▪ ゲームまとめ ▪ Mobage 一部コンポーネント • Redis • MyDNS • Memcached ◦ MySQL のバージョンアップ ◦ Memcached 構成変更 2
3. アジェンダ • システム構成の紹介 • Memcached on EC2 で発生した障害 3
4. システム構成の紹介 システム構成 • public subnet ◦ デフォルト • private subnet ◦ outbound IP を統一したい 場合のみ • Amazon EC2 サーバへの制限 ◦ セキュリティグループ 4 Internet gateway Application Load Balancer Application EC2 Memcached on EC2 DB,Redis…on EC2 Internet (outbound IP を統一したい場合) Transit gateway サービス A サービス B
5. システム構成の紹介 システム構成 • public subnet ◦ デフォルト • private subnet ◦ outbound IP を統一したい 場合のみ • Amazon EC2 サーバへの制限 ◦ セキュリティグループ 5 Internet gateway ALB Application on EC2 Memcached on EC2 DB,Redis…on EC2 Internet Transit gateway サービス A サービス B セキュリティグループで 接続を拒否 セキュリティグループで 接続を拒否 (outbound IP を統一したい場合)
6. Memcached on EC2 で発生した障害 障害内容 • ほぼ同時に複数 Memcached サーバへの 新規接続が張れなくなった • 複数の Memcached サーバが、 死活監視に失敗しアラートがとんだことです ぐに問題を検知した 6 監視サーバ Memcached1 set/get … Memcached2 Memcached3 Memcached171
7. 障害対応の流れ 1. 暫定対応 ◦ サービスへの影響を防ぐために行う一時的な対応 2. 原因調査 3. 恒久対応 7
8. 暫定対応 1. 状況確認 ◦ アラートの内容の確認 ◦ 1台のみなのか、複数台なのか ◦ 他のサービスでも起きていないか ◦ 様々な指標（CPU、MEMORY…）に変化はないか ◦ リクエスト数はどのくらいなのか 2. 暫定対応 8
9. 暫定対応 1. 状況確認 ◦ Memcached への set/get 監視が失敗した ▪ set/get ではなくその前の接続に失敗した ◦ 複数台で失敗した ◦ 他のサービスでは起きておらず、 特定のサービスに使われている Memcached サーバのみ起きている ◦ 様々な指標（CPU、MEMORY…）に異常はない ◦ リクエスト数が通常より増えている ◦ Memcached サーバへのリクエスト数が増えたことで問題が発生したと推測 2. 暫定対応 ◦ Memcached サーバを20台増設した 9
10. 原因調査 1. 状況確認 ◦ 暫定対応の時と比べてより詳細な調査 2. 状況から原因を特定 10
11. 原因調査 1. 状況確認 • CloudWatch で確認したところ NetworkPacketsIn の Average が、 一定の値に達したタイミングで問題が起きたように見えている • オンプレミス時代に同様の問題は発生していない • DeNA では認識できていない何かしらの制限が AWS 側にあると推測 • AWS テクニカルサポートに確認 11
12. 原因調査 問い合わせ結果 • Amazon EC2 では、セキュリティグループに関する制限が存在する ◦ セキュリティグループの接続の追跡 (https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) ※ 障害時にこのドキュメントは存在しなかった • Memcached サーバが 「セキュリティグループがインスタンスごとに追跡できる接続の最大数」に達していた ただし • セキュリティグループを使うと必ず制限がかかるわけではない ◦ インバウンドルールまたはアウトバウンドルールの どちらかは 0.0.0.0/0:any を許可、もうー方は 0.0.0.0/0:all(0～65535) を許可、 この場合は制限がかからない 12
13. 恒久対応 目的 • 同様の問題が起きた時にすぐに気づけるようにする • 同様の問題が起きないようにする 対応まで 1. 対応案の洗い出し 2. 各案の Pros/Cons 比較 3. 対応 13
14. 恒久対応 1. 対応案の洗い出し • コスト ◦ 実装コスト ◦ 運用コスト ◦ 稼働コスト • リスク ◦ セキュリティリスク ◦ 事故リスク 14
15. 恒久対応 1. 対応案の洗い出し • 考えられる対応 ◦ 案1：セキュリティグループを制限がかからないような設定にする ◦ 案2：Amazon ElastiCache に移行する ◦ 案3：Memcached サーバ1台あたりの接続数を少なくする 15
16. 対応案の洗い出し 案1：セキュリティグループを制限がかからないような設定にする クリアすべき要件は３つ • 要件A：セキュリティグループの設定 ◦ インバウンドルールまたはアウトバウンドルールの どちらかは 0.0.0.0/0:any を許可、もうー方は 0.0.0.0/0:all(0～65535) を許可、 この場合は制限がかからない しかも • 下記はこれまでセキュリティグループで制限していたため、 他の方法で制限しなければいけない ◦ 要件B：Internet からの接続 ◦ 要件C：他 VPC からの接続 16
17. 対応案の洗い出し 案1：セキュリティグループを制限がかからない ような設定にする ① private subnet + iptables • 要件A：セキュリティグループの設定 ◦ インバウンドルールを 0.0.0.0/0:11211 へ変更 • 要件B：Internet からの接続 ◦ private subnet へ移す • 要件C：他 VPC からの接続 ◦ ネットワーク ACL を使う ▪ ネットワーク ACL ルールが 評価されない条件にマッチ ◦ iptables を使う ただし • subnet の移動や iptables の導入に工数がかかる 実装コスト△ 17 Internet gateway ALB Application on EC2 Memcached on EC2 Internet Transit gateway iptables で拒否 private subnet だから通れない サービス A サービス B
18. 対応案の洗い出し 案1：セキュリティグループを制限がかからない ような設定にする ② public ip を付与しない + iptables • 要件A：セキュリティグループの設定 ◦ インバウンドルールを 0.0.0.0/0:11211 へ変更 • 要件B：Internet からの接続 ◦ public subnet のまま public ip の付与をしない • 要件C：他 VPC からの接続 ◦ iptables を使う しかし… • うっかり public ip を付与してしまうと侵入 される セキュリティリスク× 18 Internet gateway ALB Application on EC2 Memcached on EC2 Internet Transit gateway iptables で拒否 public ip を持たないため 接続できない
19. 対応案の洗い出し 案2：Amazon ElastiCache に移行する • セキュリティグループの制限は存在する ただし • 自動でスケーリングできれば、 リクエスト数に応じてスケーリングし 制限を回避することができる しかし… • ElastiCache for Memcached は、 Auto Scaling 機能が未実装 問題の改善につながらない 19 Internet gateway ALB Application on EC2 ElastiCache for Memcached Internet Transit gateway セキュリティグループで拒否 セキュリティグループで 拒否
20. 対応案の洗い出し 案3：Memcached サーバ1台あたりの接続数を少なくする • 実装コストが少ない ◦ Memcached サーバを増設 ◦ Memcached サーバのスペックアップ しかし… • 必要以上な台数やスペックを用意しなければならない 稼働コスト× 20
21. 恒久対応 2. 各案の Pros/Cons 比較 21 コスト リスク 実装コスト 運用コスト 稼働コスト セキュリティリスク 事故リスク 案1① △ ◯ ◯ ◯ ◯ 案1② ◯ ◯ ◯ × ◯ 案2 ー ー ー ー ー 案3 ◯ ◯ × ◯ ◯ • 案1：セキュリティグループを制限がかからないような設定にする ◦ ① private subnet + iptables ◦ ② public ip の付与をしない + ipatables • 案2：Amazon ElastiCache に移行する • 案3：Memcached サーバ1台あたりの接続数を少なくする
22. 今回の障害のまとめ 1. 暫定対応 ◦ Memcached サーバを増設 2. 原因調査 ◦ DeNA では認識できていない何かしらの制限が AWS 側にあると推測 ◦ AWS テクニカルサポートへ確認 ◦ セキュリティグループがインスタンスごとに追跡できる接続の最大数に達していた 3. 恒久対応 ◦ 案1：セキュリティグループの設定を追跡を行わない設定にする ▪ セキュリティグループのインバウンドルールを 0.0.0.0/0:11211 へ変更 ▪ private subnet へ移し Internet からの接続を防ぐ ▪ iptables を使い他 VPC からの接続を防ぐ 22
23. 最後に 振り返り • 監視を整えていたことで、問題をすぐに気づくことができた • AWS サポート※1 へ問い合わせたことで、問題の調査から対策まで丁寧に対応していただけた • 対応案の洗い出しから Pros/Cons 比較を MECE に行うことで大きな出戻りがなく、 問題に対して適切な対応ができた 23 ※1：「AWS テクニカルサポート」「テクニカルアカウントマネージャー(TAM)」「ソリューションアーキテクト(SA)」の３つ