JAWS Festa 2015 in Kyushu Ops track

1. SIerとAWS運用の
付き合い方
NRIネットコム株式会社
佐藤 瞬
2015/11/03
JAWS FESTA 2015 in KYUSHU

2. 誰？
AWS上でWebシステムの構築・運用をしています
「Amazon Web Services パターン別構築・運用ガイド」書きました
過去のスライド
http://www.slideshare.net/tenbo07
佐藤 瞬
福島県会津若松市出身
NRIネットコム株式会社（大阪勤務）
インフラエンジニア

3. Amazon Web Services
パターン別構築・運用ガイド
AWS本の中で
もっとも分厚い本です
※2回目の増刷が決まりました！！

4. ちょっと宣伝
現在、社内のメンバーでAWS本として
２冊目の執筆に取り掛かっています！！
Lambda、APIGateway、Device Farmなど、
フロント∼モバイルアプリ開発者寄りの内容になる予定です。
発売されたら、よろしくお願いします（小声）

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

6. NRIネットコム
Web周りのビジネスを専門としている会社
モバイル開発もやってます
Web ＋ DB Press vol.88
に社内のモバイルアプリ
開発メンバーが寄稿してます
「クラウドで加速！モバイ
ル開発」の部分

7. それでは、本題に入っていきます

8. 保守・運用
言うのは簡単ですが、なかなか幅広い
２４／３６５とか当たり前のようにやりますが、
実際問題かなり大変
サーバのお守りだけでなく、追加機能の開発や
バグ修正も行う必要がある
技術も日々進化しているので、安定運用を
続けながらも進化させたい

9. 今日は、AWSで稼動しているシステムを
SIerという立場でどのように運用しているか。
今まで行ってきた実例・経験を元に話していきます。

10. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメント
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

11. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメントについて
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

12. production/staging/develop

13. ３つの環境
PJの規模にもよりますが、運用する上では大抵
production/staging/developの３つの環境が必要になる
AWSは環境のコピーや再構築が容易なので、
全く同じ環境を３つ作ることも可能
しかし、それではコストがかさむので、
それぞれの目的により、効率良く構築・運用することが大事

14. production/staging/develop
それぞれの考え方

15. Production
実際にサービスが稼動する環境
基本的に24/365の運用・監視

16. Staging
本番リリース前の最終確認、お客様にリリース許可を
いただくため（UAT）の環境
外部システムとの連結テストも実施する
可能な限り本番と同様の環境とする
RDSなどのマネージドサービスも本番と同様に利用
インスタンスタイプなど性能は必要に応じて
基本的に監視は不要

17. Develop
追加機能の開発やバグ修正など、自社内の開発で
利用する環境
ビジネスロジックの確認が目的
アプリが動く最低限の環境があればよい
監視は不要
（いろんな考え方があると思いますが）

18. production/staging/develop
構築

19. Production環境の構築

20. Production環境の構築
productionアカウント
VPC
EC2
S3
RDS ELB
CloudFormation
template
（kumogata）
DynamoDB
…etcItamae
serverspec
基本コードベースで構築
環境の再現性を高める
コード化には主に２種類
AWSリソースのコード化
OS~ミドルウェア構築のコード化
（EC2インスタンス）

21. AWSリソースのコード化

22. AWSリソースのコード化
CloudFormation
AWSのリソースをJSON形式のtemplateで定義
templateに従って自動構築してくれるサービス
AWSリソースのほとんどに対応
対応してないものもたまにあるので、
そういうのは仕方ないので手で

23. AWSリソースのコード化
CloudFormationの問題
JSONがつらい。
数百行のJSONファイルができあがるので闇が深い
JSONはプログラムで使う分にはいいが、
人間が使うものではない
（※個人の感想です）

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

25. 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/

26. OS∼ミドルウェア構築のコード化
（EC2インスタンス）

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

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

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

30. Staging環境の構築

31. 基本的にProduction構築時にコードが
出来上がっているので、それをちょっと変えて流すだけ
EC2インスタンスはAMIを共有するのも有り
変更するところ
EC2、RDS、ElastiCacheなどのインスタンスタイプは
性能テスト時以外は最低限のもので
Multi-AZではなくSingle構成に
S3は同一リージョンで同じバケット名のものは
作れないので変更する
Staging環境の構築

32. Staging環境の構築
Productionアカウント Stagingアカウント
VPC
EC2
S3
RDS ELB
production
template
DynamoDB
…etc
インスタンスタイプや
S3のバケット名など変更
Staging
template
VPC
EC2
S3
RDS ELB
DynamoDB
…etc
あまり手間をかけずCloudFormationでサクッと
AMI

33. Develop環境の構築

34. ビジネスロジックの確認が目的なので、最低限の環境でよい
お客さんに見せることもなく、社内でしか使わない
マネージドサービス（RDSなど）は常に課金される
停止できないので、使わなくとも課金される
ちょっともったいない
EC2インスタンスは停止しておけば課金されない
※EBS・EIPの料金はかかりますが
スクリプトで自動起動・停止
Develop環境の構築
EC2インスタンスで済ませられないか？

35. RDS／ElastiCache／ELBはミドルウェアで代替できる
RDSは、Aurora以外であればDBエンジンを
インストールすれば同じ
ElastiCacheもRedis／mecachedをインストールして
しまえばいい
ELBはApache／nginxでリバプロすればよい
１つのEC2インスタンスでも済む
Develop環境の構築

36. VPC
EC2
S3 DynamoDB
…etc
VPC
EC2
S3
RDS ELB
DynamoDB
…etc
Productionアカウント Developアカウント
代替ができるものはEC2インスタンスに乗せる
S3やDynamoDBなど、代替の効かないものだけつかう
Develop環境の構築

37. VPC
EC2
S3 DynamoDBVPC
EC2
S3
RDS ELB
DynamoDB
nginxapp MySQL
Productionアカウント Developアカウント
しかし、同じOS上に構築のは、それぞれの依存関係により
影響が出る可能性が高いので、Dockerで構築
（最近やりはじめた）
Develop環境の構築

38. Dockerでの構築について
構築の手間はそんなにかからない
Nginx、MySQLなどは公式イメージをPullするだけ
アプリケーション用のイメージもItamaeを流すだけ
Kubernetes使って運用
コンテナが落ちた時など勝手に復旧してくれて便利
ただ、ProductionではDocker未導入です。
Develop環境なので試験的にやってます。
もうちょっと慣れてきたら本番でも？
Develop環境の構築

39. production/staging/develop
運用

40. 運用の例
Develop Staging Production
機能追加・バグ修正
アプリ開発者が
開発・検証
お客様に確認
リリースし、
本番稼動
インフラの設定変更
（主にミドルウェア）
アプリ・インフラ
を自社内で確認
本番の適用手順と
同じ手順で適用
し、稼働確認
Stagingで検証された
手順でリリース
マネージドサービスの
パッチ適用
ー
Updateを実施し、
稼働確認
Stagingで問題がなけ
れば適用
運用における使い方は従来とあまり変わりません

41. Staging／Develop環境は使わないときは停止する
マネージドサービスのパッチ適用
RDS、ElastiCache、Redshiftなど
メンテナンスウインドウを設定するサービス
自動で適用されるものあるが、再起動が必要となり
マネージドサービスが一時的に停止するものは手動で
（Upgradeを実行するだけ）
AWS特有の事項
→ マネージドサービス使うことでかなり楽になりますが、
手放しで運用できるというわけではない

42. AWSからいつまでにUpgradeしてねという通知がくる
期間を過ぎるとメンテナンス時間に強制Upgradeも
Stagingにまずは適用してみる
最初からProductionに適用するのはやっぱり危険
まずはStagingで適用し、問題なければProductionに
最近もMySQLのパッチ当てるとCPU使用率が
10%上がったり。。。
パッチ適用時はマネージドサービスも停止する場合がある
RDSが停止する場合はサービス停止もありえるので
お客さんとの調整など、いろいろ準備しておく必要がある
マネージドサービスのパッチ適用

43. 受託開発で運用していくうえでは、
従来通りproduction/staging/developは必要
AWSであれば、同じ環境を作りやすい
Staging環境は、構成は本番と同じでも性能が同じ必要はない
Develop環境でマネージドサービスが必要かどうかは
一旦考えましょう
マネージドサービスも面倒見なきゃいけない部分はある
まとめ

44. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメント
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

45. 監視

46. CloudWatch
サーバインストール型のツールを使う
Zabbix、Hinemos、Nagios etc…
SaaSを使う
mackerel、Data dog etc…
監視方法
大きく３つ
現状は、CloudWatchとZabbixでやってます

47. なぜこの監視になっているか

48. それぞれのツールについて

49. マネージドサービスのリソース状況の確認
CloudWatchでしか確認できない項目が多い
EC2インスタンスの監視としては、ちょっと厳しい
メモリ、ポート、サービスなどはそのままでは
できない
CloudWatch Logsは正規表現が使えないので、
細かくログ監視しようとするとつらい
CloudWatch
CloudWatchだけで監視するのは厳しい。
ただ、簡単にリソースを確認できるので
運用の補助ツールとしては有用

50. CloudWatchでは難しい、EC2の細かい監視
Zabbix-agent、もしくはSNMPで情報を取得
AutoScalingにも対応できる
カスタムメトリクスをうまく使えば、
CloudWatchでも細かくEC2の監視をすることは可能だが、
そこを作りこむよりzabbix-agentを入れてしまった方が早い
監視項目をテンプレート化して、使いまわせる
情報も多く、慣れている
Zabbix
基本的に監視全般をZabbixで

51. データ保持という観点

52. 継続的に運用する上では、監視データは保持しておきたい
過去の監視データがあるとイベント時の対応や予測が楽
クリスマス、初売りなど、イベント時の監視データは
残しておきたい
EC2、ELBは過去のデータに基いてスケールする
提案・見積もりでも、どの程度のリソースが必要かの
指標とすることができる
監視データの保持
データの保持というのは重要

53. CloudWatch、SaaSでのデータ保持は制限がある
CloudWatchのデータ保持期間は２週間
SaaSは保持期間を伸ばすと料金が増える
監視サーバを自前で用意する必要があるが、
Zabbixならデータを長期間保持しておける
マネージドサービスの監視データも
CloudWatchから取得してZabbixに保存
監視データの保持
自分で監視サーバを持っていた方がいいという結論
（今のところは）

54. CloudWatchだけで監視は厳しい
カスタムメトリクスで頑張ることもできるが、
そこを作りこむなら別なツールを使うべき
監視は全般的にZabbixで行っている
主に監視データの保持という観点で
監視ツールもいろいろあるのでチームにとって、
一番使いやすいものを使うのが一番だと思う
まとめ

55. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメント
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

56. ドキュメント

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

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

59. まとめ
AWSを操作するための手順書は不要
だいたいリファレンスがある
UIもしょっちゅう変わる
マネジメントコンソールを見て、
「なぜ」そうなったかわからない部分は
ドキュメントで補完する必要がある
IP表示してる部分はわからないことが多い
マネジメントコンソール見ればだいたいわかるので、
オンプレと比べたら不要な部分は多い

60. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメント
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

61. 新サービスへの対応

62. AWSはどんどん新サービスが出てくる
毎月のように新サービス・新機能が追加される
サービスが出る度に最適なアーキテクチャ・運用も変わる
新サービスを理解しておかないと、提案の品質にも関わる
古いアーキテクチャのまま提案するわけにはいかない
CodeDeploy
Config
Config RulesAPI GatewayLambda EFS
積極的に新サービスを理解していかなければならない
Machine
Learning
Service
Catalog

63. 新サービスを理解するためには
やはり触ってみることが大事

64. 問題はどこでやるか
（受託開発は自由にできる環境が少ない）

65. 主にDevelop環境で試してます
そこそこ自由に使える
何かあっても社内にしか迷惑がかからない
アプリを変更しない限りはそれなりになんでもできる
AWSはすぐに作って捨てられるので、検証が終わったら
捨てればいい
EC2インスタンスだけでなく他のサービスも
それなりにシステムが動作してるので検証としても有用
特に運用に関わるサービス・機能について

66. 最近やったこと
Lambdaのスケジュール実行＆Python対応
EC2インスタンスの自動起動・停止バッチを移行
instance
Tagの値の取得
起動 or 停止
Lambda
10分毎に実行
スケジュール実行がちゃんと動いてるのはもちろんですが、
Python意外と書けるなと思いました（バッチは元々Ruby）
（Rubyに対応してくれるに越したことはないですが）

67. 最近やったこと
Lambdaのスケジュール実行＆Python対応
ただ、ちょっと問題が

68. 最近やったこと
Lambdaのスケジュール実行＆Python対応
ただ、ちょっと問題が
Scheduled Eventの登録数に制限がある（4個？）
適当に登録してたら、それ以上登録できなくなった
しかも、要らないものを削除する方法が見当たらない・・・
なにか知ってる人いたら教えてください（切実）

69. 最近やったこと
Lambdaのスケジュール実行＆Python対応
ただ、ちょっと問題が
Forumにも上がってたので、そのうち改善される？
https://forums.aws.amazon.com/thread.jspa?messageID=682871
まだ本番で使うのは
待った方がいいかなと思いました。
（個人の感想です）

70. まとめ
AWSのアーキテクチャは常に変わっていきます
提案の品質にも関わるので、死活問題
新サービスに対応していく体制を整える必要がある
触ってみることがやはり大事なので、
試せる環境を用意する
Develop環境はちょうどいいと思います
検証用のアカウント作ってもいい
AWS SAブログや某社ブログを読むだけでなく、
手を動かして自分で理解する
いろいろ困ることが出てくるはず・・・

71. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメントについて
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

72. 今年のre:Inventで
嬉しかったもの

73. 今年もre:Inventでいろいろ出ましたね
AWS IoT
Kinesis firehose
Mobile Hub
Snowball
Lambdaのスケジュール実行、Python対応
どれも個人的にはすごくワクワクするし楽しいですが、
現在の運用業務で一番うれしかったのはこれではなく

74. Config Rules

75. 社内ガイドラインとの照合
AWSを利用する場合は、社内のガイドラインを
満たしているか毎回チェックする必要がある
ガイドラインには、なにかを定期的にチェック
しないさいといったものが多い
Excelのチェックシートに記入して、セキュリティ
部門に送るのはイケてない上めんどう
必要なことですが、
どうしてもこういう作業はモチベーションが下がる

76. Config Rulesを使えば
自動でチェックできる
一度Ruleを書いてしまえば、全部のアカウントに
使いまわせる
コードベースのチェックになるので、Gitで管理できる
チェック内容をアップデートしてもすぐ確認できる
定期的なチェックも自動でできる
もはや人がチェックする必要なし

77. Config Rulesで
セキュリティ部門を
潰そ 楽にしてあげよう

78. production/staging/develop環境
それぞれの環境の考え方
構築方法
運用
監視
ドキュメントについて
新サービスへの対応
今年のre:Inventで嬉しかったもの
まとめ

79. 全体まとめ

80. 全体まとめ
production/staging/develop環境は、同じものを作るのではなく
目的とAWSの特性を考えて効率的に
CloudWatchだけでの監視は厳しいので他のツールをうまく使う
継続運用には監視データを保持しておきたい
AWSについてのドキュメントはほとんど必要ないが、
一部必要なところはある
最適なアーキテクチャはAWSが新サービス出す度に変わる
新サービスをしっかり理解していく
Config Rulesでやっかいな社内業務を楽に

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