はじめてのAWS設計でやりがちな失敗パターンまとめ

1. にしざわ
はじめてのAWS設計でやりがちな
失敗パターンまとめ

2. ⾃⼰紹介 2
⻄澤 徹訓
• 元クラスメソッド株式会社
• 元AWS事業本部コンサルティング部
• 2015年8⽉⼊社
• まもなく44歳、O型、⾠年、蟹座
• 今は何よりも娘ちゃんが⼤事
• "⼤盛無料"と聞くと喜ぶ
• ⾒るよりもやるのが好き(球技、⾳楽など)

3. 3
今⽇話すこと

4. 今⽇のテーマ 4
•対象
• AWS初学者向け、インフラエンジニア向け
•お話する内容
• AWS環境上で初めて設計する⽅に注意して
欲しいことをまとめます
• いくつかのグループに⼤別し、過去の失敗事
例をお伝えします

5. 今⽇話さないこと 5
•AWS Well-Architected Framework(ベストプラクティス)
•AWSサービス単位での設計⽅針
•AWS上級者向けの細かい機能やノウハウ

6. 注意 6
タイトルにあえて「失敗」と書きましたが、
特定の誰かをディスる気持ちはありません
⾃分⾃⾝の反省を踏まえて、これを伝えるこ
とで誰かのお役に⽴てたら嬉しいです

7. 7
要件整理編

8. 失敗パターン 〜⼩さく試さない〜 8
「検討ばかりで実証実験に時間を割かない」
•机上での検討に時間をかけすぎて設計が進まない
•⼩さく試して失敗することを気にしすぎてしまう

9. 解決策 〜⼩さく試さない〜 9
クラウドでは⼩さく試すことを繰り返せるこ
とが⼤きなメリット
検討に時間をかけても設計は洗練されていか
ないことを理解する

10. 失敗パターン 〜クラウドで塩漬ける〜 10
「クラウド環境に塩漬けシステムを移⾏する」
•ハードウェアの保守切れ対応を避けるだけの⽬的でクラウド
移⾏してしまう
•OSやミドルウェアの保守を考えていない

11. 解決策 〜クラウドで塩漬ける〜 11
塩漬けにしたいシステムをクラウドに持って
いっても何も解決しない
移⾏の⽬的がそれしか無いのであれば計画か
ら⾒直すべき

12. 失敗パターン 〜⼊り組んだ要件〜 12
「壮⼤なピタゴラスイッチを開発する」
•AWSの各種サービスや機能を利⽤しようとしすぎて、問題
発⽣時に切り分けや復旧ができない独⾃機能を開発する
•⼯数をかけてようやく開発した機能が、AWSサービスアッ
プデートで不要になることも

13. 解決策 〜⼊り組んだ要件〜 13
その開発が本当に必要ですか？
AWSサービスのアップデートに対応できるよ
うに部品に留めた機能補完を検討

14. 参考ブログ 〜⼊り組んだ要件〜 14
https://dev.classmethod.jp/articles/aws-devday-tokyo-2019-furniture-oss/

15. 15
AWSアカウント
ネットワーク

16. 失敗パターン 〜複数サブシステム〜 16
「複数サブシステムの管理⽅針が決まっていない」
•AWSアカウント分割の⽅針を決めずに、AWSアカウントを
増やし続けたり、逆に1つのAWSアカウントに複数システム
を混在させてしまう
•AWSアカウントおよびネットワーク設計は、あとから変更
するコストが⼤きいため、当初の⽅針のまま運⽤を続けるし
かない

17. 解決策 〜複数サブシステム〜 17
AWSアカウント分割設計は事前に検討する
サブシステム、本番/テスト、セキュリティな
どの観点で要件を整理する

18. 参考ブログ 〜複数サブシステム〜 18
https://dev.classmethod.jp/articles/mutil-aws-account-strategy/

19. 失敗パターン 〜IPアドレス管理〜 19
「IPアドレスを静的に管理しようとする」
•EC2ではプライベートIPを明⽰的に指定して管理することが
できるが、それに依存した作りにすることで、再構築時の⼿
間がかかる
•VPC内に構築されるマネージドサービス（ELB、RDS、等）
が利⽤するIPアドレスを考慮が漏れ、IPが枯渇する

20. 解決策 〜IPアドレス管理〜 20
可能な限り動的管理に任せてDNSを利⽤する
マネージドサービスが消費するIPアドレスを
考慮し、余裕を持ってサブネットを定義する

21. 参考ブログ 〜IPアドレス管理〜 21
https://dev.classmethod.jp/articles/amazon-vpc-5-tips/

22. 失敗パターン 〜閉域網〜 22
「⽬的不明のまま閉域網構成にする」
•オンプレミス環境での設計の延⻑から、Direct Connectや
Site-to-Site VPN等のサービスを利⽤した閉域ネットワーク
としたが、明確なポリシーがあるわけではない
•逆に新たに構築した環境が閉域ネットワーク内にある他の重
要システムへのアクセス経路となってしまうことで意図せぬ
脅威にさらされるパターンも

23. 解決策 〜閉域網〜 23
その閉域網は本当に必要ですか？
通信をHTTPS等で暗号化し、通信元や通信先
のIPを制限することで、⼗分なセキュリティ
を担保できるケースも

24. 24
コスト管理
サイジング
その他

25. 失敗パターン 〜バーストパフォーマンスインスタンス〜 25
「コスト判断でバースト系ファミリーを選択する」
•T2、T3等のバーストパフォーマンスインスタンスは、クレ
ジット枯渇すると⼀気にベースラインまでパフォーマンスが
落ちるため、システム利⽤不可となるケースも

26. 解決策 〜バーストパフォーマンスインスタンス〜 26
⼀般公開する本番サービスではバーストパ
フォーマンスは使わない
コストパフォーマンスに優れるA1(ARMベー
ス)ファミリーも検討

27. 参考ブログ 〜バーストパフォーマンスインスタンス〜 27
https://dev.classmethod.jp/articles/ec2-t-or-m/

28. 失敗パターン 〜ディスクサイズ〜 28
「ディスクサイズを多めに⾒積もりがち」
•実態調査をせずに、⾮常に安価なオンプレ環境のディスクと
同じ感覚で⼤きなディスクサイズを割り当ててしまい、ラン
ニングコストが想定以上になってしまう
•バックアップデータをローカルに溜め込むような設計になっ
ている

29. 解決策 〜ディスクサイズ〜 29
EBSボリュームは動的に拡張可能なので、監
視しきい値を調整しつつ、後から変更する
バックアップデータは、安価で堅牢なS3等に
定期的に逃がすように

30. 参考ブログ 〜ディスクサイズ〜 30
https://dev.classmethod.jp/articles/expand-ebs-in-online/

31. 失敗パターン 〜スペック選定〜 31
「スモールスタートの幻想に縛られる」
•性能の出ない低スペックのマシンからバッチ処理の検証をス
タートした為、処理に時間がかかりすぎてしまう
•事前に検討していたコスト⾒積を節約しすぎた為に、クラウ
ドの柔軟性を活かすことができない

32. 解決策 〜スペック選定〜 32
検証時にケチりすぎるのは効率を落とすだけ
⼀時的に⼤きく作ってすぐに削除することが
できるのもクラウドのメリットであることを
お忘れなく

33. 失敗パターン 〜テスト環境構成〜 33
「本番とテストで構成が違う」
•テスト環境の費⽤を抑える為、本番とテストで異なる構成に
してしまう
•構成が異なっていることが原因で、テスト時に問題を検知で
きない

34. 解決策 〜テスト環境構成〜 34
テスト環境は可能な限り本番と同じ構成に
不要時の停⽌やスペック調整でコストコント
ロールする

35. 失敗パターン 〜バックアップ〜 35
「そもそもバックアップを取得していない」
•何かしらの原因で削除された場合、オンプレ環境のように
ディスクからサルベージするような依頼はできない
•クラウド側が起因でインスタンス上のデータが消えて無くな
ることは極めて稀だが、⼿動での誤操作は起こり得る

36. 解決策 〜バックアップ〜 36
AWSでは安く信頼性の⾼いバックアップ機能
は活⽤できる、万⼀の事態には備えておく
最低限のバックアップやログを取得しておく

37. 参考ブログ 〜バックアップ〜 37
https://dev.classmethod.jp/articles/minimize-failure-impact-on-singleaz/

38. 失敗パターン 〜組織〜 38
「クラウド推進担当におまかせ状態になる」
•会社全体でクラウドへの理解が浸透せず、特定の担当に依存
したシステム管理が⾏われてしまう
•担当者の離任によってシステムの引き継ぎ先が存在しない
ケースも

39. 解決策 〜組織〜 39
特定の担当に頼りすぎず、全社でクラウドの理
解を浸透させるための活動も並⾏して⾏う
組織がベンダー選定やシステム評価ができない
状態ではクラウドのメリットは享受できない

40. 40
まとめ

41. ここだけはお伝えしたい 41
•クラウド移⾏は⼿段のひとつでしかない
•本来の⽬的を忘れずに
•⼩さく失敗することを恐れず、改善をくりか
えすことができるのが、クラウドを取り⼊れる
最⼤のメリット

42. ありがとうございました！！！ 42
この発表の内容がどこかの誰かの
お役に⽴てば嬉しいです！