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

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を作成し、
Launchconfigを切り替える
→ デプロイ済みのインスタンスが起動する
B. インスタンスの起動時にリポジトリから
最新のアプリを取ってくる
Amazon Web Services パターン別構築・運用ガイド P272

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

33. Statelessなサーバは必ずAutoScaling

34. Beanstalkの運用

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

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

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

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

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

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

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

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

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

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

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. ご静聴ありがとうございました