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.

Slerがawsで運用してきた話

20,873 views

Published on

JAWS-UG Osaka オペレーションじょうず

Published in: Technology
  • Be the first to comment

Slerがawsで運用してきた話

  1. 1. SIerがAWSで 運用してきた話 NRIネットコム株式会社 佐藤 瞬 2015/05/23 JAWS-UG OSAKA オペレーションじょうず
  2. 2. 誰? 佐藤 瞬 NRIネットコム株式会社 福島県会津若松市出身 Amazon Web Services 
 パターン別構築・運用ガイド
 書きました Facebook
 https://www.facebook.com/sato.shun.31
  3. 3. Amazon Web Services パターン別構築・運用ガイド AWS本の中で もっとも分厚い本です ※詳しくはこちら JAWS-UG初心者支部 AWS書籍活用術 http://www.slideshare.net/takurosasaki/jawsug- beginnersbook
  4. 4. NRIネットコム Webシステムの企画・設計・開発・運用 Webディレクター/デザイナーも多数在籍 NRIグループとして国内複数ヶ所にデータセンター もちろん、AWSはじめクラウドにも力を入れています Web周りのビジネスを専門としている会社
  5. 5. 本日のテーマ 運用
  6. 6. 運用 夜間コール 腐ったドキュメント なぜか動くプログラム 属人化 落ちるサーバ 考慮漏れ 障害報告 消えたデータ
  7. 7. いろいろつらい
  8. 8. しかし、 AWSで運用をはじめたことで、 そんな運用も変わってきました
  9. 9. 今日は、AWSになって、 運用がどのように変わっていったか なにがよかったのか 実際どうやって運用しているのか といったことを、実際の運用例を元にまとめてみました。
  10. 10. 運用してきたシステムの例 レガシーなアプリケーションを載せたAWSインフラの運用 AutoScalingを使ったシステムの運用 Beanstalkの運用 ドキュメントについて 運用をもっと効率化 Infrastructure as codeの実践 まとめ
  11. 11. レガシーなアプリケーションを載せた AWSインフラの運用
  12. 12. AWS SDKが使えない(Java6以前など)
  → SQSやDynamoDBなどSDKを
     ガッツリ使うサービスを使えない Statelessでない
  → AutoScalingが難しい AWSにおける「レガシー」を以下のように定義しました
  13. 13. なぜそのようなことに? オンプレからAWSへの移行 オンプレの保守切れによりインフラ移行は必須 だが、アプリケーションは改修できない
  14. 14. SQSやDynamoDBなどは使えない AutoScalingも使えない オンプレの時とほとんど同じ構成
  15. 15. それでもAWSで運用する意味あるの?
  16. 16. AWSになることの利点 (よくあるところ) スケールアップ、スケールアウトが容易
  → 繁忙期だけスケールアップ・アウト(手動) データのバックアップについて細かく考えなくていい
  → AWSにおまかせ or スナップショットとるだけ マネージドサービスを使えば運用する必要がない
  → ネットワーク、RDS、ELB、Route53など
  → オンプレと同じ構成でも使えるものは多い 障害時にデータセンターに走らなくていい
  17. 17. さらに
  18. 18. S3の素晴らしさ オンプレであればデータの置き場は困りどころ AWSなら、どんなデータだろうが何も考えずS3に 放り込んでおけばいい
 (ログ、バックアップ、アプリケーション…etc) しかも、静的サイトもホスティングできる
 (EC2の負担が減る)
  19. 19. S3の素晴らしさ シンプルなサービスですが、 噛めば噛むほど味が出る
  20. 20. 検証環境が簡単に作れる 運用において本番と同等の検証環境は重要 AWSなら簡単に同じものを作れる ちょっとした金額で済む 使わない時は停止 or バックアップを取って削除 構成変更時のテスト、トラブル発生時の検証が楽 にできる
  21. 21. 本番アカウント 検証アカウント VPC EC2 S3 RDS ELB VPC EC2 S3 RDS ELB template 検証用 template AMI CloudFormation、CloudFormerを使うとより便利 CloudFormer CloudFormer アカウント内のAWS リソースを CloudFormation テンプレート化してくれるもの AMIはアカウント間で共有 RDSのスナップショットは共有できないので、DBの中身は検証用に作成 そもそも、個人情報など機密情報があるので、持ち出せない
  22. 22. とはいえ。
  23. 23. 障害は起きる
  24. 24. ミドルウェア、DBを しっかり設計しなければならないことは変わらない 普通の障害 EC2インスタンスは普通のサーバ ミドルウェアなど設定に不備があれば、普通に死ぬ オンプレと同じ構成だとEC2に頼りがちになる
  → 障害もEC2に集中する RDSも中身は普通のデータベース(Auroraは置いといて) クソみたいなSQL投げてたら普通に死ぬ パラメータもしっかりチューニングしないと死ぬ 障害の話
  25. 25. 障害の話 AWSサービス障害 多くはないが、全くないわけではない フルマネージドサービスを使うと運用の負担は減るが、
 障害時にはなにもしようがない AWSサービス障害の確認 大規模な障害は以下で確認
 → AWS障害情報 : http://status.aws.amazon.com/ 特定のアカウント・特定のインスタンスなど、小規模な障害は
 サポートに問い合わせなければわからない
  → おかしいと思ったら、すぐサポートに問い合わせ
  26. 26. まとめ オンプレと同じ構成でもかなり負担が減る AWSのメリットが見えやすいので、AWSの
 入口としてわかりやすい
 ※私はこれが最初のAWS関連のプロジェクトでした 乗せた後にアーキテクチャを考え直せばいい
  27. 27. AutoScalingを 使ったシステムの運用
  28. 28. AWSにインフラを乗せて、 運用が大きく変わる最初のポイントが AutoScaling
  29. 29. AutoScalingを使ったシステムの運用 運用の手間がだいぶ省ける 急なアクセス増に耐えられる EC2インスタンスが自動で復旧するようになる リリース・旧戻しが簡単 ほとんどのWebサーバはAutoScalingしています
  30. 30. 考えなければならないのが デプロイ方法
  31. 31. デプロイ方法 基本の2パターン A. 最新のアプリをデプロイしたAMIを作成し、 Launchconfigを切り替える
 → デプロイ済みのインスタンスが起動する B. インスタンスの起動時にリポジトリから
 最新のアプリを取ってくる Amazon Web Services パターン別構築・運用ガイド P272
  32. 32. 基本的にAでやってます リリースのタイミングを調整しやすい Bより安全 Bではリポジトリにコミットした瞬間にリリースされることになる 旧戻しが楽。同じようにLaunchconfig を切り替えるだけでよい 手間はかかるが、手順は自動化できるので大して問題にならない
  EC2の起動→デプロイ→AMI作成
         →LaunchConfig作成→インスタンス入れ替え ※もちろん、デプロイ方法は他にもあります
  33. 33. Statelessなサーバは必ずAutoScaling
  34. 34. Beanstalkの運用
  35. 35. AutoScalingで運用の負担はだいぶ減る でも、できればもっと Beanstalkの導入 AutoScalingで運用の負担はだいぶ減る でも、できればもっと
  36. 36. 導入の経緯 1年も使わないサイトだった 非常に簡単なアプリケーション アクセス数は読めない 細かい納品も求められなかった 設計・構築をしたくない → Beanstalkでやってみよう→ Beanstalkでやってみよう
  37. 37. 結果として なんだかんだ、それなりに設計と構築はした 監視周り(CloudWatch Logs) 特定パスのアクセス制限 など Beanstalkで一番ありがたいのは構築よりデプロイ周り
  38. 38. 運用について AutoScalingしているため、キャパシティは気にしな くてよい デプロイはコマンド一発 or マネジメントコンソール にZipをアップ で済むので楽 デプロイについて考えなくていいことが楽 インフラ周りでは運用で特に手がかからなかった
  39. 39. 今後も使うか 機会があれば使う Beanstalkに合う案件が出てくるかは微妙 単一のアプリケーションで済む 外部システムとの連携など細かい要件がない →シンプルなアプリケーションである必要がある
  40. 40. 運用してきたシステムの例 レガシーなアプリケーションを載せたAWSインフラの運用 AutoScalingを使ったシステムの運用 Beanstalkの運用 ドキュメントについて 運用をもっと効率化 Infrastructure as codeの実践 まとめ
  41. 41. ドキュメントについて
  42. 42. AWS運用でどんなドキュメントが必要か AWSリソースの設定内容など AWSマネジメントコンソールでほとんどの情報確認できる マネジメントコンソールだけでは厳しい部分は存在するので、
 そこはドキュメントが必要 手順書(AWSの操作関連) リファレンスを探せば、ほぼ確実にあるので作成不要 困ったときのリンク集のようなものは作ってもいいかもしれない
  43. 43. マネジメントコンソールだけでは厳しい部分 主にIPを表示している部分
  → Security Group、EIP、Route Table Security GroupをIP指定で開けている場合、
 そのIPがなんのIPなのかわからない Route Tableはどういった意味があるのか読み取れない EIPが特別なものではないかどうか 特定のシステムから許可されているなど 使っていなくともリリースしては困るものかどうか
  44. 44. 運用してきたシステムの例 レガシーなアプリケーションを載せたAWSインフラの運用 AutoScalingを使ったシステムの運用 Beanstalkの運用 ドキュメントについて 運用をもっと効率化 Infrastructure as codeの実践 まとめ
  45. 45. Infrastructure as Codeの実践
  46. 46. なぜやるのか? インフラのブラックボックス化を防ぐ インフラをバージョン管理することができる サーバにログインして実施していた作業を自動化できるため、
 ヒューマンエラーを防止できる いつでも同じ状態を再現できる AWSからの移行を考えた場合に重要
 → AWS使いたくともお客さん次第
  47. 47. AWSにおいては、2つのコード化がある AWSリソースのコード化 サーバ(EC2インスタンス)内部のコード化 AWSにおけるInfrastructure as code
  48. 48. 実際、どのようにやってるか
  49. 49. AWSリソースのコード化 CloudFormationを使う CloudFormationの問題 テンプレートファイルがJSON形式であること JSONはプログラムで使う分にはいいが、
   人間が使うものではない(※個人の感想です) 拡張性が悪い テンプレートファイルが長くなる 書いてて楽しくない
  50. 50. kumogata CloudFormationのテンプレートをRubyで書ける Rubyで書ける意味 コメントが記述できる 同じ処理はループで書ける ファイルを分割できる
 (require、load、includeを使う)
  51. 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. 52. サーバ内部のコード化 Chef クライアントが必要 機能が多く、便利な反面複雑 他のメンバーへの教育が大変 Ansible 手軽さと簡単さは素晴らしくいいが、Playbook がYAMLなのはつらい Pythonよく知らない → どっちもしっくりこなかった
  53. 53. Itamae ChefとAnsibleのいいとこ取りしたようなもの Rubyで書ける(ChefのようなDSL) クライアント不要(SSH経由で実行可) 覚えることが少ない。すごくシンプル
 → レシピを実行する以外の機能が特にない コア部分はSpecinfra
  54. 54. Itamaeのサンプル 以下が参考になります itamaeのテストコード
 https://github.com/itamae-kitchen/itamae/tree/master/spec/integration/recipes itamae plugin
 Githubで「itamae plugin」で検索
 → ChefのCommunity Cookbookのようなことをgemでやってる
  55. 55. テストについて サーバの状態 Serverspec 振る舞いのテスト 基本手でやってる Infratasterを使えないか検討中 テストハーネス test-kitchen kitchen-itamaeがある
 https://github.com/OpsRockin/kitchen-itamae
  56. 56. Infrastructure as codeの実践 シンプルなツールから始めるのが重要 実は一回Chefで失敗してます 他のメンバーも使えそうなツールを選ぶ 開発は一人でできても運用は一人でできない 先は長いです 運用ちゃんと回るか 他のメンバーが使えるようになるか 自分がいなくなっても続くのか サラリーマンだから(異動、転勤 or …)
  57. 57. 全体まとめ
  58. 58. 全体まとめ オンプレと同じ構成でもAWSに載せれば、それなりに幸せになれる 積極的にAutoScalingさせる Beanstalkはデプロイ周りが便利 AWSについてのドキュメントはほとんど作る必要ないが、
 一部必要なところはある kumogata、Itamaeすごくいいです
  59. 59. ご静聴ありがとうございました

×