AWS Summit Tokyo 2019 参加してきました。

エンジニアのみなさん、こんな悩みを抱えていませんか？

監視の強化や運用の効率化をして、保守を楽にしたい
高負荷時も稼動し続けられるように対策したい
悪意のある攻撃の対応に悩まされている

業務でプロダクトを運用しているとこんな状況になることがしばしばあります。もちろん弊社も例外ではありません。

そんな課題を改善すべく、知見・情報を得るために AWS Summit Tokyo 2019 に3日間とも参加してきました。

プロダクトを安定的に運用したい

プロダクトのローンチ当初は、どうしても開発スピードを要する(ビジネスの都合を優先する)ため、設計やテストを後回しにしがちになり、その結果あとでメンテする人がつらくなりがちです。 (ありがたいことですが)その状態でユーザ数が増加すると、過去の負債や設計ミスを解消する余裕ができず、安定的に稼働するのが難しくなります。

また、プロモーションやSNSのバズりなどで大規模なアクセスがきた場合に、高負荷を捌ききれずにサービスがダウンしたり、データ量の蓄積により予期せぬ障害が発生しやすくなります。

そうなった場合、監視の強化や運用の自動化の検討を進めていく必要があり、何が重要でどこから手をつけていくべきかを知りたいと考え、そのインプットとなるようなセッションを中心に聴いてきました。

ちなみに、弊社では勉強会や技術セッションの参加費を会社が負担してくれる Dev Training 制度というものがあり、今回もそれを利用させていただきました。

参加してみての印象

過去の AWS Summit には参加したことがなく、今回初めて参加してみたのですが、参加している人数やスポンサー企業がとても多く、 AWS の市場規模の大きさがうかがえました。また、企業のブースやスポンサーの宣伝ブースなどが多く、勉強会というよりはイベント色が強い印象を受けました。

得られた知見のまとめ

最初に記載した目的のとおり、以下の観点を中心にセッションを聴いてきたので、得られた知見をそれぞれまとめてみました。

監視の強化と運用の効率化

目的と数値目標を決めて、それを達成するためにどの指標を監視するか？どう運用するか？を考えるのが重要
- コストの最適化と Auto Scaling の精度を上げたい
  - => EC2 のCPU/メモリ等を監視
- 障害時のビジネス影響を最小限に抑えるために、システムの正常・異常を監視したい
  - => リソース単位ではなく、(ALB の応答時間/500エラー数など)システム全体でのメトリクスを監視項目にする
障害時の切り戻しを楽にする
- Blue/Green Deployment
- 各コンポーネントの責務を小さく
  - EC2 で状態を持たない
  - 重い処理の非同期実行の検討
  - マイクロサービスという選択肢

負荷対策

負荷テストの実施
- 複数の観点で実施し、それぞれの目的にあった負荷のかけ方をする
  - スロークエリやロックのの発見 => ユーザが取りうるシナリオを定義して負荷をかける
  - スケーリングやフェイルオーバーの確認 => 対象のコンポーネントに対してのみ負荷をかける
  - 常に稼働し続けることの確認 => 負荷をかけつつ、あえて一部のコンポーネントをダウンさせる
  - サービスの限界性能を定義する => 完全にサービスが停止するところまで負荷をかける
- 負荷テストを継続的に実施できる仕組み
  - 負荷をかける側の環境構築を楽にする ( docker image を作る)
  - 一部のコンポーネントが壊れても楽に復旧できる ( cloud formation など)
RDB 以外の選択肢
- サービス特性に応じて Dynamo DB, Elasticache などを利用する

攻撃対策

AWS Shield Advanced の利用
- 組み込んであるロジックによって、攻撃(と判断したアクセス)を防御してくれる
- CloudWatch に DDoS に特化したメトリクスを提供
- 攻撃の検知状況と緩和状況を可視化
- AWS の DDoS 対策チーム(DRT)への相談ができる
- DDoS により余計に課金されたもの( DDoS でスケーリングされた EC2 など)の返金サービス
AWS セキュリティワークショップの利用
- 実際に攻撃をしてくれて、評価をしてくれるサービス
- 実際に稼働しているサービスとは別アカウントを利用する (実際に攻撃されてしまうため)

感想

参加してみて特に印象に残ったこととしては「負荷試験は奥が深い！」ということでした。言われてみれば当たり前なのですが、高負荷時の振る舞いを確認したいのであれば確認観点は複数あり、それを実際にシュミレートしてあげる必要があると改めて思いました。また、もうひとつ印象に残った言葉としては「適切な責任分界を行った結果としてマイクロサービスになる」です。マイクロサービスに踏み切るかどうかではなく、適切な責任分界にするとどうなるか？を考えるのが重要だと感じました。

以上、読んでいただきありがとうございました。ちなみに来年の AWS Summit Tokyo は横浜で開催するとのことです。それでは！