資料公開 「今から始めるAWS設計 ～Well-Archなシステムを作ろう～」というテーマで喋りました #devio2021

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな ネクストモード株式会社 の吉井です。

DevelopersIO 2021 Decade の DAY 2 ライブセッション「今から始めるAWS設計 ～Well-Archなシステムを作ろう～」に登壇しました。その資料を公開します。

資料

サマリ

セッション概要

オンプレミスのシステム群をAWSへ移行したい方々、移行してみたものの本格的な設計まで着手できていない方々に向けてWell-Archなシステム設計手法をオンプレミスとの違いを交えて解説します。

最適な移行戦略を選択

システム、サブシステム、サーバーごとに要件に合致した最適な移行戦略を選択します。
必ずしもリファクタ－、リプラットフォームが正解ではありません。

ネットワーク

• オンプレミスとの接続方法を接続パターンごとに選択
• サブネットはフラットに
• CloudFront、WAF の導入を検討してみてください

コンピュート

EC2

• EC2 AutoRecovery おすすめ
• とにかくスモールスタート
• t 系インスタンスは特性を理解して使う

EC2 と別れを

• 「手がかからない」システムにしたい
• コンテナ化への道のり

データベース

• RDBMS on EC2 vs Aurora,RDS
• 正解はない

運用

• 運用モデルの再構築
• バックアップ、自動で取得しておく
• オペレーションはイベント契機で
• AWS 設計上の可用性
• DR はどこまでやるのか？
• AWS 起因の障害に備える

AWS Well-Architected フレームワーク

• 原則はあくまで原則
• 要件がまずある

質問と回答

Q1 EC2 AutoRecovery でリカバリーされる場合、どの時点のものが使われるのでしょうか？

もともと起動していた EC2 が強制シャットダウンされた時点の状態でリカバリーされます。
EBS ボリュームに保存されていたデータはリカバリー後もご利用いただけます。

vMotion などのように稼働したままリカバリーされるわけではなく、一度シャットダウン→ブートアップになります。

Q2-1 ecsでfargateを仕様した場合のメリットとしてセキュリティ系のアップデートを自動で適用してくれる、というのがあると思うのですが、rpmパッケージ以外にもアップデートされるのでしょうか？EC2でcronを使ってyum update --securityを毎日実施するのとどう異なりますか？

データプレーンのセキュリティアップデートの質問と理解しました。

Fargate の内部構造は公開されていないので、セキュリティアップデートに何が含まれているのかは回答がありません。ご理解ください。
詳細: Fargate データプレーン に少しヒントが書かれているかもしれません。

Q2-2 ecsでセキュリティの件で質問した者です。ecsでコンテナの実行環境としてec2とfargateを比較した場合、ec2でyum updateを自動で行うのとfargateのセキュリティ自動アップデートは自分で自動アップデートの設定をするかどうかの違いくらいでしょうか？それともセキュリティアップデートの内容はfargateとec2で異なるのでしょうか？

個人的には Fargate と ECS 最適化 AMI は、重大なセキュリティイシューの更新についてはほぼ同時に更新されていると思います。
更新を適用するには Fargate なら Force New Deployment、最適化 AMI なら AMI の差し替えを行います。
最適化 AMI を使わず自前で EC2 を運用されている場合の yum update との比較は何とも判断ができない次第です。ご理解いただければと思います。

Q3 コンテナではなく、EC2にするほうがよいと判断した事例などあれば教えていただけるでしょうか？（判断軸が知りたい）

一番最初に思い浮かぶのはパッケージソフトウェアの利用です。
パッケージソフトウェアは EC2 を使わざるを得ないケースがあると思います。

マシンパワー (CPU、メモリ、I/O) を必要するケースでも EC2 のほうが優位である可能性が高いと思います。

コンテナ化するまでもない小さなバッチが多数ある仮想サーバーをそのまま EC2 で稼働させた経験もございます。

Q4 DRで東京だけでまかなえるか検討するにしてもデータセンターのロケーションは公開されてないと思うのですが判断する材料は他に何かあるのでしょうか？

まずは「何に備えるか」を定義します。

データセンター内部のハードウェア、サーバーラック、電源、空調等環境設備の故障に備えるのであれば東京リージョンのみでまかなえます。

東京近郊の広域な災害や停電に備えるのであれば大阪や他リージョンで DR を構成します。
ただ、AWS 利用料金や DR 対応をする技術者のコストが発生することになるので、DR 発生確率とそれに係るコストはバランスをとって検討ください。

東京リージョンの自体の大規模障害に備えるケースでも大阪や他リージョンで DR を構成します。

以上、吉井 亮 がお届けしました。