Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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

  • Be the first to comment

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

  1. 1. にしざわ はじめてのAWS設計でやりがちな 失敗パターンまとめ
  2. 2. ⾃⼰紹介 2 ⻄澤 徹訓 • 元クラスメソッド株式会社 • 元AWS事業本部コンサルティング部 • 2015年8⽉⼊社 • まもなく44歳、O型、⾠年、蟹座 • 今は何よりも娘ちゃんが⼤事 • "⼤盛無料"と聞くと喜ぶ • ⾒るよりもやるのが好き(球技、⾳楽など)
  3. 3. 3 今⽇話すこと
  4. 4. 今⽇のテーマ 4 •対象 • AWS初学者向け、インフラエンジニア向け •お話する内容 • AWS環境上で初めて設計する⽅に注意して 欲しいことをまとめます • いくつかのグループに⼤別し、過去の失敗事 例をお伝えします
  5. 5. 今⽇話さないこと 5 •AWS Well-Architected Framework(ベストプラクティス) •AWSサービス単位での設計⽅針 •AWS上級者向けの細かい機能やノウハウ
  6. 6. 注意 6 タイトルにあえて「失敗」と書きましたが、 特定の誰かをディスる気持ちはありません ⾃分⾃⾝の反省を踏まえて、これを伝えるこ とで誰かのお役に⽴てたら嬉しいです
  7. 7. 7 要件整理編
  8. 8. 失敗パターン 〜⼩さく試さない〜 8 「検討ばかりで実証実験に時間を割かない」 •机上での検討に時間をかけすぎて設計が進まない •⼩さく試して失敗することを気にしすぎてしまう
  9. 9. 解決策 〜⼩さく試さない〜 9 クラウドでは⼩さく試すことを繰り返せるこ とが⼤きなメリット 検討に時間をかけても設計は洗練されていか ないことを理解する
  10. 10. 失敗パターン 〜クラウドで塩漬ける〜 10 「クラウド環境に塩漬けシステムを移⾏する」 •ハードウェアの保守切れ対応を避けるだけの⽬的でクラウド 移⾏してしまう •OSやミドルウェアの保守を考えていない
  11. 11. 解決策 〜クラウドで塩漬ける〜 11 塩漬けにしたいシステムをクラウドに持って いっても何も解決しない 移⾏の⽬的がそれしか無いのであれば計画か ら⾒直すべき
  12. 12. 失敗パターン 〜⼊り組んだ要件〜 12 「壮⼤なピタゴラスイッチを開発する」 •AWSの各種サービスや機能を利⽤しようとしすぎて、問題 発⽣時に切り分けや復旧ができない独⾃機能を開発する •⼯数をかけてようやく開発した機能が、AWSサービスアッ プデートで不要になることも
  13. 13. 解決策 〜⼊り組んだ要件〜 13 その開発が本当に必要ですか? AWSサービスのアップデートに対応できるよ うに部品に留めた機能補完を検討
  14. 14. 参考ブログ 〜⼊り組んだ要件〜 14 https://dev.classmethod.jp/articles/aws-devday-tokyo-2019-furniture-oss/
  15. 15. 15 AWSアカウント ネットワーク
  16. 16. 失敗パターン 〜複数サブシステム〜 16 「複数サブシステムの管理⽅針が決まっていない」 •AWSアカウント分割の⽅針を決めずに、AWSアカウントを 増やし続けたり、逆に1つのAWSアカウントに複数システム を混在させてしまう •AWSアカウントおよびネットワーク設計は、あとから変更 するコストが⼤きいため、当初の⽅針のまま運⽤を続けるし かない
  17. 17. 解決策 〜複数サブシステム〜 17 AWSアカウント分割設計は事前に検討する サブシステム、本番/テスト、セキュリティな どの観点で要件を整理する
  18. 18. 参考ブログ 〜複数サブシステム〜 18 https://dev.classmethod.jp/articles/mutil-aws-account-strategy/
  19. 19. 失敗パターン 〜IPアドレス管理〜 19 「IPアドレスを静的に管理しようとする」 •EC2ではプライベートIPを明⽰的に指定して管理することが できるが、それに依存した作りにすることで、再構築時の⼿ 間がかかる •VPC内に構築されるマネージドサービス(ELB、RDS、等) が利⽤するIPアドレスを考慮が漏れ、IPが枯渇する
  20. 20. 解決策 〜IPアドレス管理〜 20 可能な限り動的管理に任せてDNSを利⽤する マネージドサービスが消費するIPアドレスを 考慮し、余裕を持ってサブネットを定義する
  21. 21. 参考ブログ 〜IPアドレス管理〜 21 https://dev.classmethod.jp/articles/amazon-vpc-5-tips/
  22. 22. 失敗パターン 〜閉域網〜 22 「⽬的不明のまま閉域網構成にする」 •オンプレミス環境での設計の延⻑から、Direct Connectや Site-to-Site VPN等のサービスを利⽤した閉域ネットワーク としたが、明確なポリシーがあるわけではない •逆に新たに構築した環境が閉域ネットワーク内にある他の重 要システムへのアクセス経路となってしまうことで意図せぬ 脅威にさらされるパターンも
  23. 23. 解決策 〜閉域網〜 23 その閉域網は本当に必要ですか? 通信をHTTPS等で暗号化し、通信元や通信先 のIPを制限することで、⼗分なセキュリティ を担保できるケースも
  24. 24. 24 コスト管理 サイジング その他
  25. 25. 失敗パターン 〜バーストパフォーマンスインスタンス〜 25 「コスト判断でバースト系ファミリーを選択する」 •T2、T3等のバーストパフォーマンスインスタンスは、クレ ジット枯渇すると⼀気にベースラインまでパフォーマンスが 落ちるため、システム利⽤不可となるケースも
  26. 26. 解決策 〜バーストパフォーマンスインスタンス〜 26 ⼀般公開する本番サービスではバーストパ フォーマンスは使わない コストパフォーマンスに優れるA1(ARMベー ス)ファミリーも検討
  27. 27. 参考ブログ 〜バーストパフォーマンスインスタンス〜 27 https://dev.classmethod.jp/articles/ec2-t-or-m/
  28. 28. 失敗パターン 〜ディスクサイズ〜 28 「ディスクサイズを多めに⾒積もりがち」 •実態調査をせずに、⾮常に安価なオンプレ環境のディスクと 同じ感覚で⼤きなディスクサイズを割り当ててしまい、ラン ニングコストが想定以上になってしまう •バックアップデータをローカルに溜め込むような設計になっ ている
  29. 29. 解決策 〜ディスクサイズ〜 29 EBSボリュームは動的に拡張可能なので、監 視しきい値を調整しつつ、後から変更する バックアップデータは、安価で堅牢なS3等に 定期的に逃がすように
  30. 30. 参考ブログ 〜ディスクサイズ〜 30 https://dev.classmethod.jp/articles/expand-ebs-in-online/
  31. 31. 失敗パターン 〜スペック選定〜 31 「スモールスタートの幻想に縛られる」 •性能の出ない低スペックのマシンからバッチ処理の検証をス タートした為、処理に時間がかかりすぎてしまう •事前に検討していたコスト⾒積を節約しすぎた為に、クラウ ドの柔軟性を活かすことができない
  32. 32. 解決策 〜スペック選定〜 32 検証時にケチりすぎるのは効率を落とすだけ ⼀時的に⼤きく作ってすぐに削除することが できるのもクラウドのメリットであることを お忘れなく
  33. 33. 失敗パターン 〜テスト環境構成〜 33 「本番とテストで構成が違う」 •テスト環境の費⽤を抑える為、本番とテストで異なる構成に してしまう •構成が異なっていることが原因で、テスト時に問題を検知で きない
  34. 34. 解決策 〜テスト環境構成〜 34 テスト環境は可能な限り本番と同じ構成に 不要時の停⽌やスペック調整でコストコント ロールする
  35. 35. 失敗パターン 〜バックアップ〜 35 「そもそもバックアップを取得していない」 •何かしらの原因で削除された場合、オンプレ環境のように ディスクからサルベージするような依頼はできない •クラウド側が起因でインスタンス上のデータが消えて無くな ることは極めて稀だが、⼿動での誤操作は起こり得る
  36. 36. 解決策 〜バックアップ〜 36 AWSでは安く信頼性の⾼いバックアップ機能 は活⽤できる、万⼀の事態には備えておく 最低限のバックアップやログを取得しておく
  37. 37. 参考ブログ 〜バックアップ〜 37 https://dev.classmethod.jp/articles/minimize-failure-impact-on-singleaz/
  38. 38. 失敗パターン 〜組織〜 38 「クラウド推進担当におまかせ状態になる」 •会社全体でクラウドへの理解が浸透せず、特定の担当に依存 したシステム管理が⾏われてしまう •担当者の離任によってシステムの引き継ぎ先が存在しない ケースも
  39. 39. 解決策 〜組織〜 39 特定の担当に頼りすぎず、全社でクラウドの理 解を浸透させるための活動も並⾏して⾏う 組織がベンダー選定やシステム評価ができない 状態ではクラウドのメリットは享受できない
  40. 40. 40 まとめ
  41. 41. ここだけはお伝えしたい 41 •クラウド移⾏は⼿段のひとつでしかない •本来の⽬的を忘れずに •⼩さく失敗することを恐れず、改善をくりか えすことができるのが、クラウドを取り⼊れる 最⼤のメリット
  42. 42. ありがとうございました!!! 42 この発表の内容がどこかの誰かの お役に⽴てば嬉しいです!

×