Slerがawsで運用してきた話

1. SIerがAWSで運用してきた話 NRIネットコム株式会社佐藤瞬 2015/05/23 JAWS-UG OSAKA オペレーションじょうず

2. 誰？佐藤瞬 NRIネットコム株式会社福島県会津若松市出身 Amazon Web Services   パターン別構築・運用ガイド  書きました Facebook  https://www.facebook.com/sato.shun.31

3. Amazon Web Services パターン別構築・運用ガイド AWS本の中でもっとも分厚い本です ※詳しくはこちら JAWS-UG初心者支部 AWS書籍活用術 http://www.slideshare.net/takurosasaki/jawsug- beginnersbook

4. NRIネットコム Webシステムの企画・設計・開発・運用 Webディレクター／デザイナーも多数在籍 NRIグループとして国内複数ヶ所にデータセンターもちろん、AWSはじめクラウドにも力を入れています Web周りのビジネスを専門としている会社

5. 本日のテーマ運用

6. 運用夜間コール腐ったドキュメントなぜか動くプログラム属人化落ちるサーバ考慮漏れ障害報告消えたデータ

7. いろいろつらい

8. しかし、 AWSで運用をはじめたことで、そんな運用も変わってきました

9. 今日は、AWSになって、運用がどのように変わっていったかなにがよかったのか実際どうやって運用しているのかといったことを、実際の運用例を元にまとめてみました。

10. 運用してきたシステムの例レガシーなアプリケーションを載せたAWSインフラの運用 AutoScalingを使ったシステムの運用 Beanstalkの運用ドキュメントについて運用をもっと効率化 Infrastructure as codeの実践まとめ

11. レガシーなアプリケーションを載せた AWSインフラの運用

12. AWS SDKが使えない（Java6以前など）  → SQSやDynamoDBなどSDKを  ガッツリ使うサービスを使えない Statelessでない  → AutoScalingが難しい AWSにおける「レガシー」を以下のように定義しました

13. なぜそのようなことに？オンプレからAWSへの移行オンプレの保守切れによりインフラ移行は必須だが、アプリケーションは改修できない

14. SQSやDynamoDBなどは使えない AutoScalingも使えないオンプレの時とほとんど同じ構成

15. それでもAWSで運用する意味あるの？

16. AWSになることの利点（よくあるところ）スケールアップ、スケールアウトが容易  → 繁忙期だけスケールアップ・アウト（手動）データのバックアップについて細かく考えなくていい  → AWSにおまかせ or スナップショットとるだけマネージドサービスを使えば運用する必要がない  → ネットワーク、RDS、ELB、Route53など  → オンプレと同じ構成でも使えるものは多い障害時にデータセンターに走らなくていい

17. さらに

18. S3の素晴らしさオンプレであればデータの置き場は困りどころ AWSなら、どんなデータだろうが何も考えずS3に放り込んでおけばいい  （ログ、バックアップ、アプリケーション…etc）しかも、静的サイトもホスティングできる  （EC2の負担が減る）

19. S3の素晴らしさシンプルなサービスですが、噛めば噛むほど味が出る

20. 検証環境が簡単に作れる運用において本番と同等の検証環境は重要 AWSなら簡単に同じものを作れるちょっとした金額で済む使わない時は停止 or バックアップを取って削除構成変更時のテスト、トラブル発生時の検証が楽にできる

21. 本番アカウント検証アカウント VPC EC2 S3 RDS ELB VPC EC2 S3 RDS ELB template 検証用 template AMI CloudFormation、CloudFormerを使うとより便利 CloudFormer CloudFormer アカウント内のAWS リソースを CloudFormation テンプレート化してくれるもの AMIはアカウント間で共有 RDSのスナップショットは共有できないので、DBの中身は検証用に作成そもそも、個人情報など機密情報があるので、持ち出せない

22. とはいえ。

23. 障害は起きる

24. ミドルウェア、DBをしっかり設計しなければならないことは変わらない普通の障害 EC2インスタンスは普通のサーバミドルウェアなど設定に不備があれば、普通に死ぬオンプレと同じ構成だとEC2に頼りがちになる  → 障害もEC2に集中する RDSも中身は普通のデータベース（Auroraは置いといて）クソみたいなSQL投げてたら普通に死ぬパラメータもしっかりチューニングしないと死ぬ障害の話

25. 障害の話 AWSサービス障害多くはないが、全くないわけではないフルマネージドサービスを使うと運用の負担は減るが、  障害時にはなにもしようがない AWSサービス障害の確認大規模な障害は以下で確認  → AWS障害情報： http://status.aws.amazon.com/ 特定のアカウント・特定のインスタンスなど、小規模な障害は  サポートに問い合わせなければわからない  → おかしいと思ったら、すぐサポートに問い合わせ

26. まとめオンプレと同じ構成でもかなり負担が減る AWSのメリットが見えやすいので、AWSの  入口としてわかりやすい  ※私はこれが最初のAWS関連のプロジェクトでした乗せた後にアーキテクチャを考え直せばいい

27. AutoScalingを使ったシステムの運用

28. AWSにインフラを乗せて、運用が大きく変わる最初のポイントが AutoScaling

29. AutoScalingを使ったシステムの運用運用の手間がだいぶ省ける急なアクセス増に耐えられる EC2インスタンスが自動で復旧するようになるリリース・旧戻しが簡単ほとんどのWebサーバはAutoScalingしています

30. 考えなければならないのがデプロイ方法

31. デプロイ方法基本の２パターン A. 最新のアプリをデプロイしたAMIを作成し、 Launchconﬁgを切り替える  → デプロイ済みのインスタンスが起動する B. インスタンスの起動時にリポジトリから  最新のアプリを取ってくる Amazon Web Services パターン別構築・運用ガイド P272

32. 基本的にAでやってますリリースのタイミングを調整しやすい Bより安全 Bではリポジトリにコミットした瞬間にリリースされることになる旧戻しが楽。同じようにLaunchconﬁg を切り替えるだけでよい手間はかかるが、手順は自動化できるので大して問題にならない  EC2の起動→デプロイ→AMI作成  →LaunchConﬁg作成→インスタンス入れ替え ※もちろん、デプロイ方法は他にもあります

33. Statelessなサーバは必ずAutoScaling

34. Beanstalkの運用

35. AutoScalingで運用の負担はだいぶ減るでも、できればもっと Beanstalkの導入 AutoScalingで運用の負担はだいぶ減るでも、できればもっと

36. 導入の経緯１年も使わないサイトだった非常に簡単なアプリケーションアクセス数は読めない細かい納品も求められなかった設計・構築をしたくない → Beanstalkでやってみよう→ Beanstalkでやってみよう

37. 結果としてなんだかんだ、それなりに設計と構築はした監視周り（CloudWatch Logs）特定パスのアクセス制限など Beanstalkで一番ありがたいのは構築よりデプロイ周り

38. 運用について AutoScalingしているため、キャパシティは気にしなくてよいデプロイはコマンド一発 or マネジメントコンソールにZipをアップで済むので楽デプロイについて考えなくていいことが楽インフラ周りでは運用で特に手がかからなかった

39. 今後も使うか機会があれば使う Beanstalkに合う案件が出てくるかは微妙単一のアプリケーションで済む外部システムとの連携など細かい要件がない →シンプルなアプリケーションである必要がある

41. ドキュメントについて

42. AWS運用でどんなドキュメントが必要か AWSリソースの設定内容など AWSマネジメントコンソールでほとんどの情報確認できるマネジメントコンソールだけでは厳しい部分は存在するので、  そこはドキュメントが必要手順書（AWSの操作関連）リファレンスを探せば、ほぼ確実にあるので作成不要困ったときのリンク集のようなものは作ってもいいかもしれない

43. マネジメントコンソールだけでは厳しい部分主にIPを表示している部分  → Security Group、EIP、Route Table Security GroupをIP指定で開けている場合、  そのIPがなんのIPなのかわからない Route Tableはどういった意味があるのか読み取れない EIPが特別なものではないかどうか特定のシステムから許可されているなど使っていなくともリリースしては困るものかどうか

45. Infrastructure as Codeの実践

46. なぜやるのか？インフラのブラックボックス化を防ぐインフラをバージョン管理することができるサーバにログインして実施していた作業を自動化できるため、  ヒューマンエラーを防止できるいつでも同じ状態を再現できる AWSからの移行を考えた場合に重要  → AWS使いたくともお客さん次第

47. AWSにおいては、２つのコード化がある AWSリソースのコード化サーバ（EC2インスタンス）内部のコード化 AWSにおけるInfrastructure as code

48. 実際、どのようにやってるか

49. AWSリソースのコード化 CloudFormationを使う CloudFormationの問題テンプレートファイルがJSON形式であること JSONはプログラムで使う分にはいいが、  人間が使うものではない（※個人の感想です）拡張性が悪いテンプレートファイルが長くなる書いてて楽しくない

50. kumogata CloudFormationのテンプレートをRubyで書ける Rubyで書ける意味コメントが記述できる同じ処理はループで書けるファイルを分割できる  （require、load、includeを使う）

51. kumogata 詳しくはGithubのリポジトリを  https://github.com/winebarrel/kumogata Web+DB Press 2015年2 月号  http://gihyo.jp/magazine/wdpress/archive/2015/vol85 Codenize.tools kumogata以外にもAWSのコード化に便利なツールが  ってます  http://codenize.tools/

52. サーバ内部のコード化 Chef クライアントが必要機能が多く、便利な反面複雑他のメンバーへの教育が大変 Ansible 手軽さと簡単さは素晴らしくいいが、Playbook がYAMLなのはつらい Pythonよく知らない → どっちもしっくりこなかった

53. Itamae ChefとAnsibleのいいとこ取りしたようなもの Rubyで書ける（ChefのようなDSL）クライアント不要（SSH経由で実行可）覚えることが少ない。すごくシンプル  → レシピを実行する以外の機能が特にないコア部分はSpecinfra

54. Itamaeのサンプル以下が参考になります itamaeのテストコード  https://github.com/itamae-kitchen/itamae/tree/master/spec/integration/recipes itamae plugin  Githubで「itamae plugin」で検索  → ChefのCommunity Cookbookのようなことをgemでやってる

55. テストについてサーバの状態 Serverspec 振る舞いのテスト基本手でやってる Infratasterを使えないか検討中テストハーネス test-kitchen kitchen-itamaeがある  https://github.com/OpsRockin/kitchen-itamae

56. Infrastructure as codeの実践シンプルなツールから始めるのが重要実は一回Chefで失敗してます他のメンバーも使えそうなツールを選ぶ開発は一人でできても運用は一人でできない先は長いです運用ちゃんと回るか他のメンバーが使えるようになるか自分がいなくなっても続くのかサラリーマンだから（異動、転勤 or …）

57. 全体まとめ

58. 全体まとめオンプレと同じ構成でもAWSに載せれば、それなりに幸せになれる積極的にAutoScalingさせる Beanstalkはデプロイ周りが便利 AWSについてのドキュメントはほとんど作る必要ないが、  一部必要なところはある kumogata、Itamaeすごくいいです

59. ご静聴ありがとうございました

Slerがawsで運用してきた話

Sato Shun

Transcript