おれのAWSが こんなに辛い訳がない！！

JAWS-UG広島　第18回勉強会 で発表したスライドです。

Transcript

1. おれのAWSが こんなに辛い訳がない！！ JAWS-UG広島 第18回勉強会
2. 自己紹介 金田 晃（HN) 所属：某株式会社 I like Cloud . I like AWS  AWS SDK for JavaScript 興味のあること  nodeJS  電子工作（分解・破壊・修理）  Kintone API  自宅（Docker)サーバ
3. 障害に始まり 障害に終わる
4. • AWSを使っていく中で知見不足、経験不足 など様々やらかしてきました • その中で軽めのものを10個ピックアップ • 大人の事情でナレッジ的なものは別の機会 に・・・
5. やらかしNO1 AWSサポートに加入しない • 大人の事情で(ry • 世の中にはNDAというものがあるので勉強会とかで気軽に聞 けない • 大事なことはググれないと知れ • クラメソブログで知った気になってませんか？ • それ実際やってみました？ • 担当営業に聞きまくると返事が来なくなる • 基本インフラって死にゲーだし・・・ねぇ
6. 解決策 AWSサポートに加入する • 実際にやってみる（AWS全般そうですけど） • 会社で自由に使えるアカウントを付与する • クラメソブログは書き手によっては内容が微妙省略されている • AWS公式ドキュメントを読む • 日本語のドキュメントは古かったり翻訳が微妙だったりす る • 良く分からないブログやQiitaは鵜呑みにしないこと • 前提となる環境や条件が不明なので・・・
7. やらかしNO2 RDS文字コード未設定 • RDSのデフォルト文字コードはMySQLだとLaten 1、 PostgreSQLだとen_US-UTF8 • XAMPとか物理だと設定コピペであまり意識しない • 21世紀なんだしクラウドなんだからデフォルトUTF8だろ！！ • 実はアプリ側は気づいていたようだが、そんなもんと思って いたらしく（途中から）アプリ側で変換していたらしい・・ • っが、後にソート順がおかしいとお客さんからクレームにOrz • ダンプから戻すのに異なる文字コードが混入・・無事死亡
8. 解決策 パラメタグループ作成してから作れ！！ • RDSでデータベース作成する前にパラメタグループを作る • デフォルトパラメータグループを使うな！ • 開発環境などでちゃんと構築練習すること • DBパラメタはシステム構築時に検討すること • RDSでは一部変更不可のものがある • DBは罠が多いうえに切り替えは死ぬので検討に時間をかけろ • EC2上に作るのはオススメしない
9. やらかしNO3 RDSタイムゾーン未設定 • リージョンによるのか？と思ったそんなこともなく • 文字コードと一緒でオンプレでは意識しなかった • アプリ側も意識していないことが多いので意外と盲点になる
10. 解決策 仕様検討時に盛り込んで必ず実験する • 日中に検証すると９時間ずれても気づかないことがある • ブラウザのタイムゾーンやOSの設定で良しなに動くことがある • アプリ側と認識を合わせる事 • 検証可能な環境の準備、テスト項目の列挙 • レビュー時にチェックすること
11. やらかしNO4 メンテナンスタイムで死亡 • 何故か妥協を許さないコスト重視のお客さんほどEC2単品、 RDS単品なのに完全無停止を求められる • 妥協して深夜にメンテナンスタイムを設定、自動適用にする • 翌朝画面が真っ白で怒られる・・・ • 完全無停止なんて幻想なんだから、がっつり止めさせろ！
12. 解決策 完全無停止の幻想を捨てろ！ • お客様との合意事項に計画停止、緊急時適用事項などを盛り 込む • 脆弱性がらみの緊急パッチ適用やインスタンス不良はある • 何十億円かけて作った銀行システムでも止まる • 止まったときのサブプランを持っておく • 復旧させられる障害レベルの想定と復旧手段、避難訓練的な 検証をしておく
13. やらかしNO5 EC2インスタンスが古い。マイクロばかり。 • 古いインスタンスはやがて処分される • （クラウドの裏は物理です！！） • リタイヤインスタンス続出→再起動後起動しないものがぽつぽ つ • PV→HVMの時はインスタンスタイプの切り替えが出来なかった • 移行がとても手間、ダウンタイム・・・ • （大人の事情で）マイクロばかりでスワップで頑張る。 • 空きメモリが数メガバイト→辛い・・とても辛い・・
14. 解決策 リプレイス計画を盛り込んでおく • クラウドの実態は巨大なオンプレ • クラウドといえどリプレイスからは免れられない • 予算と時間と人を構築時から計画しておく • 場合によってはコンテナ、サーバレス等も設計時検討する • 構築時にインスタンス移行を検討、実験してみると安心 • お金かけてEC2複数台構成にしておく • インスタンスサイズは余裕をもって！！
15. やらかしNO6 ElastiCache(Memcached)の選定時 メモリしか見なかった • ElastiCacheの選定時、メモリしか見ず、マイクロでいいだろ と選定 • 負荷テスト時、なぜかパフォーマンスが上がらない • EC2やRDSも負荷が上がらず、ElastiCacheの空きもある • おそらくインスタンスサイズによる帯域が頭打ちになった • せめてインスタンスごとの最低帯域載せませんか？
16. 解決策 必要なネットワーク帯域を意識する • 正直厳しい • 帯域保証のインスタンスは無い（よね？） • クラウドの裏側は仮想ネットワークが張り巡らされている • パフォーマンスが出ないときの検討事項として頭に入れとく
17. やらかしNO7 本番環境で引っかかるAPI制限 • AWSには様々なAPI制限がある • 今どれくらい使っているのか簡単に知る方法がほぼない • EC2とか一部はコンパネができた • 本番環境でかつ最大アクセス数の負荷テストをするのは困難 • 引っかかったAPIが緩和不可の場合構成から見直しになるので 詰む • 緩和申請がなかなか交渉と時間がかかる • せっかくのクラウドなのにスケールの足を引っ張るのでほん と何とかしてほしい！
18. 解決策 AWSサポートにアドバイスをもらう • 正直開発時に制限を意識するのは無理 • ミニマムスタートの場合かなり辛い • 可能なら負荷テストをして炙り出す • ちゃんとエラーログを吐く、通知をする！ • CloudTrail・・・ • 制限値については英語のドキュメントを読むこと！
19. やらかしNO8 インスタンス在庫切れ • アクセス集中の時刻に合わせてインスタンスサイズを変更 • しかしインスタンスの在庫切れで失敗！！ • 迫る時刻、より上位のインスタンスは費用増加なので上長の 承認が・・・ • リザーブドは事実上の資産管理を強いられるので辛い
20. 解決策 スケールアウトの構成にする • リザーブドインスタンスで確保する手もあるが・・・ • インスタンスが売り切れるってのを知らない人が意外と多 い？ • 様々な理由で単一インスタンス、スケールアップしか手段が 取れない場合、売り切れた場合の想定をしておきましょう。 • インスタンスサイズによってエフェメラル領域があったりな かったりするので注意！（SWAPとか）
21. やらかしNO9 便利な自動化も時には・・・ • サーバレスで構成する場合、構成要素が多いのでデプロイ自動化 はほぼ必須 • しかし、残念ながらすべてが自動化できるわけではない • すべての操作がAPIやCloudFormation化できない • 手動で作成する部分、デプロイ手順を記録に残さないといけない • 自動化した場合、自動化する環境自身が陳腐化してしまい、現代 で動かせない＆ブラックボックスで中身が分からんとかに • DBは他のリソースと一緒に構築してはいけない！！！！
22. 解決策 リプレイスする気合を取っておく • 構成管理や自動化はあくまで手段 • ドキュメントを手厚く作っておく • 構成管理の設定ファイルなどにはコメントを沢山入れておく • 最悪時間がかかっても手動で構築出来るようにしておく • ツールは流行り廃りが早い。情報のキャッチアップを！ • オレオレ構成管理ツールは担当者がリプレイスされることがある ぞ！
23. やらかしNO10 マスタアカウントで動く夜間バッチ • AWSが出始めた頃、マスタアカウントで何でも動かす • IAM is 何？良く分からないものは触らない方がいい・・ • 後にこれはアカンとIAMを作る • 気が付くとIAMが30個とかに膨れる • アカウントの棚卸をしないと・・ • 何故かマスタアカウントで深夜にS3アクセスしているの がいるのですが・・どこ？？（涙 • 今は対策されています。
24. 解決策 AWSアカウントを分離する • １つのAWSアカウント内に全部を詰め込まない • サポート費用を節約する以上のリスクが潜在してない？ • Organizations等を使いAWSアカウントを分離 • そのうえでIAMを作る • IAMではなく、IAMロールを使うといい場合がある • 共用アカウントをやめろ • アカウント発行前に使用用途を聞く • クロスアカウントを作る • いっその事外部からAWSを調達する
25. まとめ • ぶっちゃけAWSは物理のネットワークや運用経験がない と辛い • サーバレスになるとその辺りは幾分楽 • 課金ゲーなので金でわりかし何とかなる • クラウドになるから永久に持つ訳じゃない。むしろオン プレより寿命が短いので、数年でリプレイスを計画に入 れるべし。 • 特にサーバレスは半強制的にバージョンアップ • 作り変えるのが面倒になった段階で爆弾を抱えている • それ本当にクラウドじゃないとだめですか？