Rakuten Technology Conference 2019 @Sapporo

1. AWSにおける
「無理のない運用が出来るシステム構成」
を聞いてもらいたい
AWS事業本部 コンサルティング部
ソリューションアーキテクト 吉江 健斗

2. 2
• 吉江 健斗 (@yoshi_k1989)
• AWS事業部所属 ソリューションアーキテクト
Mackerelアンバサダー
• 入社/AWS歴：約3年5ヶ月
• 好きなAWSサービス
• CloudWatch
• SystemsManager
• ECS

3. 鼻で笑わないで。 3
「無理のない運用が出来るシステム」
なんて存在するのか？

4. そもそもの無理あるシステム構成とは？ 4
• 絶対に止められないシステム
• 最低限のコストで動かすシステム
• 拡張性が難しいのシステム
• 英雄的エンジニアが作ったシステム

5. 絶対に止められないシステム 5
どういったタイプのシステム？
• 企業の基幹にあたるサービス
• 企業が組織として存続させるためのサービスや製品
• 内部バッチシステム
• 夜間バッチ、定期バッチ、
• 特定業種のシステム
• 金融系、医療系、情報通信系、官公庁系… あれ？全業種ですね。

6. 最低限のコストで動かすシステム 6
どういったタイプのシステム？
• 発生コストがハッキリと分析されていないサービスを
使ったシステム
• 金額コスト,運用コスト,環境変更コスト
• 存在しないよりも存在してほしいシステム

7. 拡張性が難しいのシステム、英雄的エンジニアが作ったシステム 7
どういったタイプのシステム？
• コンポーネントが用意に置き換えられないシステム
• 例)DBエンジンの変更がしづらい
• 再現性が皆無のシステム
• インフラに関する資料が存在しない
• インフラのコード管理が徹底していない

8. 手のかかる子供ほどかわいい 8
システムとは大きい子供そのもの

9. 9
少しでも早く親孝行してくれる
大人になってもらうために何が必要か
伝えたい

10. モノづくりが大変なのはみんな同じ 10
環境構築

11. 環境構築に対する恩恵 11
• 環境構築特化のサービスやAPIによってコード管理が追加されたことで作業工数の削減され、
プログラマブルな構築が可能になった
• インフラ環境テストの導入(k1LoW/awspec)
• 2種類の環境構築が対応できるようになった
• コードによる環境構築
• で広く知られているインフラリソースをコード化することによる環境構築
• JSON/YAMLファイルやプログラミング言語によって使用リソースを定義、一括構築が可能
• 同様の環境構築を実現しやすく作業工数が小さくなる
• 手作業による構築
• 古き良き伝統的な構築手法
• サーバー管理面で構成管理ツールの利用
• 細かい変更点に対応しやすい

12. 環境構築に対する注意点① 12
環境構築へのアプローチが増えたことで課題点が生まれた
• 作業工数
• コードによる環境構築は全ての要件が決定することが大前提となる
• コードに記載されている内容のみ実現することから要件策定が未完の状態では構築が進まない
• 手作業による環境構築は同環境の複製を行うことには不向き
• 本番/STG/DEV環境のように使途別の環境構築は同設定であることが前提となる
• ＜環境数 x 1環境あたりの工数＞が成り立つ

13. 環境構築に対する注意点② 13
• レイヤー分割が必須
• モノリシックなテンプレートは様々なリソースへ影響を及ぼす懸念がある
• 影響範囲を限定的にするためにはレイヤー分割が必須
• プログラム設計における結合度/強度を考慮
モノリステンプレート図を配置 分割テンプレート図を配置

14. コードによる環境構築が難しい要因 14
コードによる管理を続けることは難しい
Infrastructure as Codeが似た分野として挙げられるが全て踏襲するのは骨が折れる
• 「最新状態」を維持することは難しい
• IaCに必要なのは「インフラコード」と「環境の現状」がイコールである必要がある
• インフラをコード管理することは手作業による環境変更を受け入れるリスクを考慮せねばならない
• 新しく環境を構築することは簡単、環境を維持することが難しい
• スノーフレークサーバーの徹底排除
• Webサーバーのような同様の役割を持たない、特殊なサーバーの存在を許容してはいけない
• インフラのコード管理
• 手作業で管理するコストがコードを管理するコストに変わる
• コード文化が許容される環境であればコストは低くなる
• 頻繁にインフラの見直しが行われない環境が良いと思われる
.
├── EC2_Cfn_template.yaml
├── EC2_Cfn_template.yaml_20190123
├── VPC_Cfn_template.yaml
├── VPC_Cfn_template.yaml_20191019
├── VPC_Cfn_template.yaml_new
└── VPC_Cfn_template.yaml_new_yoshie_update

15. コードによる環境構築が難しい要因(CloudFormation) 15
• AWS謹製のプロビジョニングツール
【メリット】
• JSONとYAMLによるリソース定義が見やすい
• 新サービスの対応が早く、ドキュメントのアップデート頻度が早い
• AWSサポートへの問い合わせやAWS Blackbeltで分かりやすい解説を聞ける
【デメリット】
• スタック(Cfnおける管理単位)のアップデートを実施する際、レイヤー分離を徹底しないと
予期せぬリソース変更が走ってしまう可能性あり
• 「潰しが効かない」技術であることを飲み込む
• validation-checkが若干弱い

16. コードによる環境構築が難しい要因(Terraform) 16
• Hashicorp社が提供しているプロビジョニングツール
• HCL(HashiCorp Configuration Language)と呼ばれるファイルで管理
• テンプレートの作成結果はtf.stateファイルとして出力される
【メリット】
• Providerとして扱える対象が非常に多い(Terraform Provider)
• AWS/Azure/GCPはもちろん、VMware vSphereやOpenStack,CloudStack,Nutanixも管理可
• マルチクラウド構成では、tf/tf.stateファイルを管理することで共有が行いやすい
• 運用中の環境のエクスポートが可能
【デメリット】
• HCLの学習コスト
• 独特の記載方法のため、多少学習コストは発生するがそんなに難しいことはない
• tf.stateが迷子になったら辛い
• S3などのファイルをバージョニングして管理出来る場所に配置することがおすすめ

17. 無理をしない環境にするために 17
• 子定規もほどほどに
• コード管理と手作業による構築の良いところを部分取りが
幸せかもしれない
• 環境の役割分担は徹底的に
• 管理方法問わず、役割分担(レイヤー分離)は運用作業中の
トラブルシュートに大きく影響を及ぼす
• コード管理を行う環境ではコード不備による影響を局所化することが可能
• 疎結合は正義
• 疎結合なシステム構成は変更コストが低くなりやすく、リフトアンドシフトが
しやすくなる

18. 運用保守のベストプラクティスを日々知りたい 18
運用保守

19. クラウドに対して持ちたくなる夢 19
クラウドが登場することで運用方法が変わりつつある
• マネージドサービスの登場
• マネージドサービスを使っているからメンテしなくて良い?
• マネージドサービスは壊れない?
• 運用管理に着目したツールの標準提供
• 監視系サービスの拡充(リソース/ログ監視,APM)
• 多種多様なサービスとの連携性
• AWSのサービスならどんなものでも簡単に繋げられる?

20. マネージドサービスにおける恩恵と注意点 20
マネージドサービスとは？ ※AWS Managed Servicesとは違います
• クラウド事業者側が特定部分の管理を代行してくれるサービス
• ホスト自体のパッチや障害対応におけるダウンタイムの最小化を代行
• マネージドサービスの対象サービスは壊れないのか？
• スケーラビリティや可用性面を対応してくれるが、影響が発生する場合も存在する
• 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
• Design For Failureの重要性
• 「全てのものは壊れる前提」
• SPOFの排除、ステートレス構成、壊れた後に直す方法の確立
• 【参考リンク】[AWS White Belt Online Seminar] AWS のよくある都市伝説とその真実：レポート #AWSBlackBelt
• 【参考リンク】【セッションレポート】Chaos Engineering ∼入門と実例∼を現地で見ました！【#AWSDevDay】

21. 運用管理に着目したツールの標準提供における恩恵と注意 21
• ユーザーが手を動かさずに監視を実現できる
• リソース利用状況は常に保存される(CloudWatch)
• ログ集約をストレージを気にせず使用可、ログ分析の合わせ技も実現
(CloudWatchLogs/CloudWatchLogs Insight)
• 比較的ローコストで監視環境を構えることは可能だが、一部でコストが割高に
なる可能性あり
• APMが利用可能に
• Serverless時代の到来に合わせてAPMを使用することが可能
• <Amazon EC2/Amazon ECS(EKS)/AWS Lambda> + AWS X-Ray

22. 多種多様なサービスとの連携性における恩恵と注意 22
• AWS内部の各種リソースとの連携容易性
• IAMを利用することでリソース間連携を実現
• 詳細な制限をJSONで記載が可能
• AWS管理ポリシーと独自ポリシーの違いを把握する必要がある
• AWS管理ポリシー：AWS側がお世話を行うポリシー
• 独自ポリシー：ユーザーがお世話をする必要がある
• 各種外部SaaSとの連携
• 一時Tokenを発行するサービスを利用して外部SaaS連携が可能
• 監視SaaS ：NewRelic / Datadog /SignalFX
• ログ分析SaaS：Sumologic

23. 無理をしない運用にするために 23
• 継続提供をテーマで考える
• マネージドサービスを取り入れるだけではなく、常に代替
品を使える環境を目指す
• モニタリングによってあらゆる処理を見える化
• より正確で適切な処理を実現するためには測定
• 「推測するな、計測せよ」はいい言葉ですね