Slerとaws運用の付き合い方

Slerとaws運用の付き合い方

1. 1. SIerとAWS運用の     付き合い方 NRIネットコム株式会社 佐藤 瞬 2015/11/03 JAWS FESTA 2015 in KYUSHU
2. 2. 誰？ AWS上でWebシステムの構築・運用をしています 「Amazon Web Services パターン別構築・運用ガイド」書きました 過去のスライド
 http://www.slideshare.net/tenbo07 佐藤 瞬 福島県会津若松市出身 NRIネットコム株式会社（大阪勤務） インフラエンジニア
3. 3. Amazon Web Services パターン別構築・運用ガイド AWS本の中で もっとも分厚い本です ※2回目の増刷が決まりました！！
4. 4. ちょっと宣伝 現在、社内のメンバーでAWS本として     ２冊目の執筆に取り掛かっています！！ Lambda、APIGateway、Device Farmなど、 フロント∼モバイルアプリ開発者寄りの内容になる予定です。 発売されたら、よろしくお願いします（小声）
5. 5. NRIネットコム Webシステムの企画・設計・開発・運用 Webディレクター／デザイナーも多数在籍 NRIグループとして国内複数ヶ所にデータセンター もちろん、AWSはじめクラウドにも力を入れています Web周りのビジネスを専門としている会社
6. 6. NRIネットコム Web周りのビジネスを専門としている会社 モバイル開発もやってます Web ＋ DB Press vol.88
 に社内のモバイルアプリ
 開発メンバーが寄稿してます 「クラウドで加速！モバイ ル開発」の部分
7. 7. それでは、本題に入っていきます
8. 8. 保守・運用 言うのは簡単ですが、なかなか幅広い ２４／３６５とか当たり前のようにやりますが、
 実際問題かなり大変 サーバのお守りだけでなく、追加機能の開発や
 バグ修正も行う必要がある 技術も日々進化しているので、安定運用を
 続けながらも進化させたい
9. 9. 今日は、AWSで稼動しているシステムを SIerという立場でどのように運用しているか。 今まで行ってきた実例・経験を元に話していきます。
10. 10. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメント 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
11. 11. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメントについて 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
12. 12. production/staging/develop
13. 13. ３つの環境 PJの規模にもよりますが、運用する上では大抵
 production/staging/developの３つの環境が必要になる AWSは環境のコピーや再構築が容易なので、
 全く同じ環境を３つ作ることも可能 しかし、それではコストがかさむので、
 それぞれの目的により、効率良く構築・運用することが大事
14. 14. production/staging/develop それぞれの考え方
15. 15. Production 実際にサービスが稼動する環境 基本的に24/365の運用・監視
16. 16. Staging 本番リリース前の最終確認、お客様にリリース許可を
 いただくため（UAT）の環境 外部システムとの連結テストも実施する 可能な限り本番と同様の環境とする RDSなどのマネージドサービスも本番と同様に利用 インスタンスタイプなど性能は必要に応じて 基本的に監視は不要
17. 17. Develop 追加機能の開発やバグ修正など、自社内の開発で
 利用する環境 ビジネスロジックの確認が目的 アプリが動く最低限の環境があればよい 監視は不要 （いろんな考え方があると思いますが）
18. 18. production/staging/develop 構築
19. 19. Production環境の構築
20. 20. Production環境の構築 productionアカウント VPC EC2 S3 RDS ELB CloudFormation template （kumogata） DynamoDB …etcItamae serverspec 基本コードベースで構築 環境の再現性を高める コード化には主に２種類 AWSリソースのコード化 OS~ミドルウェア構築のコード化 （EC2インスタンス）
21. 21. AWSリソースのコード化
22. 22. AWSリソースのコード化 CloudFormation AWSのリソースをJSON形式のtemplateで定義 templateに従って自動構築してくれるサービス AWSリソースのほとんどに対応 対応してないものもたまにあるので、
 そういうのは仕方ないので手で
23. 23. AWSリソースのコード化 CloudFormationの問題 JSONがつらい。 数百行のJSONファイルができあがるので闇が深い JSONはプログラムで使う分にはいいが、
           人間が使うものではない
             （※個人の感想です）
24. 24. kumogata CloudFormationのテンプレートをRubyで書ける Rubyで書ける意味 コメントが記述できる 同じ処理はループで書ける ファイルを分割できる
 （require、load、includeを使う）
25. 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. 26. OS∼ミドルウェア構築のコード化 （EC2インスタンス）
27. 27. Chef クライアントが必要 機能が多く、便利な反面複雑 他のメンバーへの教育が大変 Ansible 手軽さと簡単さは素晴らしくいいが、Playbook がYAMLなのはつらい Pythonよく知らない → どっちもしっくりこなかった OS∼ミドルウェア構築のコード化
28. 28. Itamae ChefとAnsibleのいいとこ取りしたようなもの Rubyで書ける（ChefのようなDSL） クライアント不要（SSH経由で実行可） 覚えることが少ない。すごくシンプル
 → レシピを実行する以外の機能が特にない コア部分はSpecinfra
29. 29. Itamaeのサンプル 以下が参考になります itamaeのテストコード
 https://github.com/itamae-kitchen/itamae/tree/master/spec/integration/recipes itamae plugin
 Githubで「itamae plugin」で検索
 → ChefのCommunity Cookbookのようなことをgemでやってる
30. 30. Staging環境の構築
31. 31. 基本的にProduction構築時にコードが
 出来上がっているので、それをちょっと変えて流すだけ EC2インスタンスはAMIを共有するのも有り 変更するところ EC2、RDS、ElastiCacheなどのインスタンスタイプは
 性能テスト時以外は最低限のもので Multi-AZではなくSingle構成に S3は同一リージョンで同じバケット名のものは
 作れないので変更する Staging環境の構築
32. 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. 33. Develop環境の構築
34. 34. ビジネスロジックの確認が目的なので、最低限の環境でよい お客さんに見せることもなく、社内でしか使わない マネージドサービス（RDSなど）は常に課金される 停止できないので、使わなくとも課金される ちょっともったいない EC2インスタンスは停止しておけば課金されない
  ※EBS・EIPの料金はかかりますが スクリプトで自動起動・停止 Develop環境の構築 EC2インスタンスで済ませられないか？
35. 35. RDS／ElastiCache／ELBはミドルウェアで代替できる RDSは、Aurora以外であればDBエンジンを
 インストールすれば同じ ElastiCacheもRedis／mecachedをインストールして しまえばいい ELBはApache／nginxでリバプロすればよい １つのEC2インスタンスでも済む Develop環境の構築
36. 36. VPC EC2 S3 DynamoDB …etc VPC EC2 S3 RDS ELB DynamoDB …etc Productionアカウント Developアカウント 代替ができるものはEC2インスタンスに乗せる S3やDynamoDBなど、代替の効かないものだけつかう Develop環境の構築
37. 37. VPC EC2 S3 DynamoDBVPC EC2 S3 RDS ELB DynamoDB nginxapp MySQL Productionアカウント Developアカウント しかし、同じOS上に構築のは、それぞれの依存関係により 影響が出る可能性が高いので、Dockerで構築 （最近やりはじめた） Develop環境の構築
38. 38. Dockerでの構築について 構築の手間はそんなにかからない Nginx、MySQLなどは公式イメージをPullするだけ アプリケーション用のイメージもItamaeを流すだけ Kubernetes使って運用 コンテナが落ちた時など勝手に復旧してくれて便利 ただ、ProductionではDocker未導入です。 Develop環境なので試験的にやってます。 もうちょっと慣れてきたら本番でも？ Develop環境の構築
39. 39. production/staging/develop 運用
40. 40. 運用の例 Develop Staging Production 機能追加・バグ修正 アプリ開発者が 開発・検証 お客様に確認 リリースし、 本番稼動 インフラの設定変更 （主にミドルウェア） アプリ・インフラ を自社内で確認 本番の適用手順と 同じ手順で適用 し、稼働確認 Stagingで検証された 手順でリリース マネージドサービスの
 パッチ適用 ー Updateを実施し、 稼働確認 Stagingで問題がなけ れば適用 運用における使い方は従来とあまり変わりません
41. 41. Staging／Develop環境は使わないときは停止する マネージドサービスのパッチ適用 RDS、ElastiCache、Redshiftなど
 メンテナンスウインドウを設定するサービス 自動で適用されるものあるが、再起動が必要となり
 マネージドサービスが一時的に停止するものは手動で
 （Upgradeを実行するだけ） AWS特有の事項 → マネージドサービス使うことでかなり楽になりますが、
   手放しで運用できるというわけではない
42. 42. AWSからいつまでにUpgradeしてねという通知がくる 期間を過ぎるとメンテナンス時間に強制Upgradeも Stagingにまずは適用してみる 最初からProductionに適用するのはやっぱり危険 まずはStagingで適用し、問題なければProductionに 最近もMySQLのパッチ当てるとCPU使用率が
 10%上がったり。。。 パッチ適用時はマネージドサービスも停止する場合がある RDSが停止する場合はサービス停止もありえるので
 お客さんとの調整など、いろいろ準備しておく必要がある マネージドサービスのパッチ適用
43. 43. 受託開発で運用していくうえでは、
 従来通りproduction/staging/developは必要 AWSであれば、同じ環境を作りやすい Staging環境は、構成は本番と同じでも性能が同じ必要はない Develop環境でマネージドサービスが必要かどうかは
 一旦考えましょう マネージドサービスも面倒見なきゃいけない部分はある まとめ
44. 44. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメント 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
45. 45. 監視
46. 46. CloudWatch サーバインストール型のツールを使う Zabbix、Hinemos、Nagios etc… SaaSを使う mackerel、Data dog etc… 監視方法 大きく３つ 現状は、CloudWatchとZabbixでやってます
47. 47. なぜこの監視になっているか
48. 48. それぞれのツールについて
49. 49. マネージドサービスのリソース状況の確認 CloudWatchでしか確認できない項目が多い EC2インスタンスの監視としては、ちょっと厳しい メモリ、ポート、サービスなどはそのままでは
 できない CloudWatch Logsは正規表現が使えないので、
 細かくログ監視しようとするとつらい CloudWatch CloudWatchだけで監視するのは厳しい。 ただ、簡単にリソースを確認できるので 運用の補助ツールとしては有用
50. 50. CloudWatchでは難しい、EC2の細かい監視 Zabbix-agent、もしくはSNMPで情報を取得 AutoScalingにも対応できる カスタムメトリクスをうまく使えば、
 CloudWatchでも細かくEC2の監視をすることは可能だが、
 そこを作りこむよりzabbix-agentを入れてしまった方が早い 監視項目をテンプレート化して、使いまわせる 情報も多く、慣れている Zabbix 基本的に監視全般をZabbixで
51. 51. データ保持という観点
52. 52. 継続的に運用する上では、監視データは保持しておきたい 過去の監視データがあるとイベント時の対応や予測が楽 クリスマス、初売りなど、イベント時の監視データは
 残しておきたい EC2、ELBは過去のデータに基いてスケールする 提案・見積もりでも、どの程度のリソースが必要かの
 指標とすることができる 監視データの保持 データの保持というのは重要
53. 53. CloudWatch、SaaSでのデータ保持は制限がある CloudWatchのデータ保持期間は２週間 SaaSは保持期間を伸ばすと料金が増える 監視サーバを自前で用意する必要があるが、
 Zabbixならデータを長期間保持しておける マネージドサービスの監視データも
 CloudWatchから取得してZabbixに保存 監視データの保持 自分で監視サーバを持っていた方がいいという結論 （今のところは）
54. 54. CloudWatchだけで監視は厳しい カスタムメトリクスで頑張ることもできるが、
 そこを作りこむなら別なツールを使うべき 監視は全般的にZabbixで行っている 主に監視データの保持という観点で 監視ツールもいろいろあるのでチームにとって、
 一番使いやすいものを使うのが一番だと思う まとめ
55. 55. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメント 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
56. 56. ドキュメント
57. 57. AWS運用でどんなドキュメントが必要か AWSリソースの設定内容など AWSマネジメントコンソールでほとんどの情報確認できる マネジメントコンソールだけでは厳しい部分は存在するので、
 そこはドキュメントが必要 手順書（AWSの操作関連） リファレンスを探せば、ほぼ確実にあるので作成不要 困ったときのリンク集のようなものは作ってもいいかも
 しれない
58. 58. マネジメントコンソールだけでは厳しい部分 主にIPを表示している部分
  → Security Group、EIP、Route Table Security GroupをIP指定で開けている場合、
 そのIPがなんのIPなのかわからない Route Tableはどういった意味があるのか読み取れない EIPが特別なものではないかどうか 特定のシステムから許可されているなど 使っていなくともリリースしては困るものかどうか
59. 59. まとめ AWSを操作するための手順書は不要 だいたいリファレンスがある UIもしょっちゅう変わる マネジメントコンソールを見て、
 「なぜ」そうなったかわからない部分は
 ドキュメントで補完する必要がある IP表示してる部分はわからないことが多い マネジメントコンソール見ればだいたいわかるので、
 オンプレと比べたら不要な部分は多い
60. 60. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメント 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
61. 61. 新サービスへの対応
62. 62. AWSはどんどん新サービスが出てくる 毎月のように新サービス・新機能が追加される サービスが出る度に最適なアーキテクチャ・運用も変わる 新サービスを理解しておかないと、提案の品質にも関わる 古いアーキテクチャのまま提案するわけにはいかない CodeDeploy Config Config RulesAPI GatewayLambda EFS 積極的に新サービスを理解していかなければならない Machine Learning Service 
 Catalog
63. 63. 新サービスを理解するためには やはり触ってみることが大事
64. 64. 問題はどこでやるか （受託開発は自由にできる環境が少ない）
65. 65. 主にDevelop環境で試してます そこそこ自由に使える 何かあっても社内にしか迷惑がかからない アプリを変更しない限りはそれなりになんでもできる AWSはすぐに作って捨てられるので、検証が終わったら 捨てればいい EC2インスタンスだけでなく他のサービスも それなりにシステムが動作してるので検証としても有用 特に運用に関わるサービス・機能について
66. 66. 最近やったこと Lambdaのスケジュール実行＆Python対応 EC2インスタンスの自動起動・停止バッチを移行 instance Tagの値の取得 起動 or 停止 Lambda 10分毎に実行 スケジュール実行がちゃんと動いてるのはもちろんですが、
 Python意外と書けるなと思いました（バッチは元々Ruby） （Rubyに対応してくれるに越したことはないですが）
67. 67. 最近やったこと Lambdaのスケジュール実行＆Python対応 ただ、ちょっと問題が
68. 68. 最近やったこと Lambdaのスケジュール実行＆Python対応 ただ、ちょっと問題が Scheduled Eventの登録数に制限がある（4個？） 適当に登録してたら、それ以上登録できなくなった しかも、要らないものを削除する方法が見当たらない・・・ なにか知ってる人いたら教えてください（切実）
69. 69. 最近やったこと Lambdaのスケジュール実行＆Python対応 ただ、ちょっと問題が Forumにも上がってたので、そのうち改善される？ https://forums.aws.amazon.com/thread.jspa?messageID=682871 まだ本番で使うのは 待った方がいいかなと思いました。 （個人の感想です）
70. 70. まとめ AWSのアーキテクチャは常に変わっていきます 提案の品質にも関わるので、死活問題 新サービスに対応していく体制を整える必要がある 触ってみることがやはり大事なので、
            試せる環境を用意する Develop環境はちょうどいいと思います 検証用のアカウント作ってもいい AWS SAブログや某社ブログを読むだけでなく、
 手を動かして自分で理解する いろいろ困ることが出てくるはず・・・
71. 71. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメントについて 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
72. 72. 今年のre:Inventで 嬉しかったもの
73. 73. 今年もre:Inventでいろいろ出ましたね AWS IoT Kinesis firehose Mobile Hub Snowball Lambdaのスケジュール実行、Python対応 どれも個人的にはすごくワクワクするし楽しいですが、 現在の運用業務で一番うれしかったのはこれではなく
74. 74. Config Rules
75. 75. 社内ガイドラインとの照合 AWSを利用する場合は、社内のガイドラインを
 満たしているか毎回チェックする必要がある ガイドラインには、なにかを定期的にチェック しないさいといったものが多い Excelのチェックシートに記入して、セキュリティ 部門に送るのはイケてない上めんどう 必要なことですが、 どうしてもこういう作業はモチベーションが下がる
76. 76. Config Rulesを使えば 自動でチェックできる 一度Ruleを書いてしまえば、全部のアカウントに
 使いまわせる コードベースのチェックになるので、Gitで管理できる チェック内容をアップデートしてもすぐ確認できる 定期的なチェックも自動でできる もはや人がチェックする必要なし
77. 77. Config Rulesで セキュリティ部門を 潰そ 楽にしてあげよう
78. 78. production/staging/develop環境 それぞれの環境の考え方 構築方法 運用 監視 ドキュメントについて 新サービスへの対応 今年のre:Inventで嬉しかったもの まとめ
79. 79. 全体まとめ
80. 80. 全体まとめ production/staging/develop環境は、同じものを作るのではなく
 目的とAWSの特性を考えて効率的に CloudWatchだけでの監視は厳しいので他のツールをうまく使う 継続運用には監視データを保持しておきたい AWSについてのドキュメントはほとんど必要ないが、
 一部必要なところはある 最適なアーキテクチャはAWSが新サービス出す度に変わる 新サービスをしっかり理解していく Config Rulesでやっかいな社内業務を楽に
81. 81. ご静聴ありがとうございました