AWS運用専門の勉強会「Ops JAWS#1」に参加してきました #jawsug #opsjaws
ウィスキー、シガー、パイプをこよなく愛する大栗です。 AWS運用管理コミュニティが主催するAWS運用に関する勉強会Ops JAWS#1に参加したのでレポートしてみます。
開会の挨拶
はじめはOps JAWSの紹介から、と思ったらまずは乾杯から
OpsJAWSとは？
- AWS運用管理領域のノウハウをまとめて、広く発信することを目的に活動を開始
- はじめは、参加者固定で、アウトプット重視で活動 Partner SAブログに記事を掲載中 AWS運用管理コミュニティ
- AWS Summit 2015の後のJAWS-UGでお披露目。多数のご好評を頂き、晴れてこの度オープン化
なおロゴは仮で、募集中とのことです！
ワーキンググループ的な活動
- エンタープライズなメンバー＋その道の専門家によるディスカッション！
- ミッションは、AWS運用Tips集の作成＆発信（Partner SAブログ）
- 月に1〜2度の頻度で実施中
- テーマに応じて毎回参加者を変更
ユーザーグループ的な活動
- 他のJAWSと同様、オープンなイベントを1ヶ月半に1度開催（努力目標）
- 広く、外部の団体や有権者と積極的にコラボ予定（意気込み）
- スピーカーのみなさま
- オペレーションじょうず：比企さん
- JAWS-UG アーキテクチャ専門支部：波田野さん
- 10月にはOSC（Open Source Conference）にも出店予定
- 運営メンバーは3人（コレが現実です。はい。）
- 伊藤さん
- 長妻さん
- 宮越さん
Q. 他のJAWS-UGとなんか違うよね？ A. よく言われますｗ エンタープライズ色は強い？とも。 一応あくまでユーザーグループです。 ですが、運用をキーワードに、ツールベンダー、サービスプロバイダとは連携したいと思ってます。
Q. コミュニティ活動に参加したいんだけど？ A. 1ヶ月半毎にイベント開催予定です。 Twitter、Facebook、Doorkeeperで告知します。 ぜひご参加ください。 運営メンバーも募集中です。 一緒にイベント企画＆運営やりましょう。 興味がある方はこの後話しましょう。
Q. ワーキンググループ（WG）に参加できるの？ A. 例えば、掲載中のTipsのフィードバックや、「おれ、わたし、ならばこんな記事がかける！」と言う、ネタをお持ちの方はぜひお声がけ下さい。 別途WG側でのディスカッション参加や執筆をお願いさせていただきたいと考えてます。
Q. んで、今日は何をやるの？ A. 初回なので、広めにテーマを設定して、クラウド時代の運用、、、
- 何が変わる？どう変わるべきか？（波田野さん）
- では実際の運用現場では？（新谷さん） 最後に知って得する＆明日から使える
- AWSサポート利用Tips（関山さん）
クラウド時代の運用エンジニアは何が変わるのか？
まずは、運用設計ラボの波田野さんの発表です。 波田野さんのオンプレミス運用と運用自動化の経験を元に、今後の運用について「サービス」と「デリバリ」という２つの視点で発表していただきました。
オンプレミスとIaas、PaaS、SaaSを資産型と費用型という視点で捉え、サービス価値とデリバリ価値を重視した運用とは何か？を述べて頂きました。 Iaas、PaaS、SaaSの運用の中で「サービス価値」、「エンジニアリング価値」を考えると『サービス価値が無いと「運用」の存在意義がない』と断言されていました。 自前主義の時代は終焉し、マネージドサービスの時代へ変化することで、優位性がないことや自前で出来ないことをマネージドサービスへ任せる必要が出てきました。
これからのインフラエンジニアは、一部のスーパーエンジニアはクラウドの中に行きデリバリ価値を提供し、大多数のエンジニアは上位レイヤーの独自性が求められる領域でサービス価値を提供することになるでしょう。
まとめ
- あらゆることが根本的に変わる
- カネが変わる
- 時間が変わる
- やり方が変わる
- サービス価値が無い「運用」は存在価値がなくなる
- 自前主義から、マネージドサービスの活用
なお、MSPは「真面目で 凄い プロバイダ」、「丸投げ サービス プロバイダ」の略のようですよｗ
cloudpack MSP運用の表と裏
cloudpack MSPセクションの新谷さんの発表です。
cloudpackの技術系セクション説明及び連携
- 設計・構築運用セクション
- MSPセクション
- 開発セクション
- 社内インフラ・Scurity＆NWセクション
-
原則運用はMSPにて行う 他のセクションは運用に載せるまで
- 各セクションは引き継ぎ資料をMSPに提出 Backlogのwikiを活用
- 引継ぎ資料に無い対応はエスカレーション お客様への一次連絡はMSPにて行う
MSPセクションの役割
- 定例業務
- アラート監視
- 環境構築
- 通常依頼対応
- 運用設計
※：cloudpackではアラート（障害）対応は24/365で行っているが依頼対応は原則営業時間帯の受付となっている
シフト
- 通常シフト ：10:00 - 19:00
- 早シフト ： 8:00 - 17:00
- 遅シフト ：14:00 - 23:00
- 夜間シフト ：23:00 - 8:00
※：夜間は通常シフトは無し
MSP運用とSOC2対応
SOC2ってご存じですか？
参考：cloudpackにおけるSOC2 type1報告書とは何か
なぜcloudpackでSOC2運用を行うのか
- クラウドってセキュリティは大丈夫なの？ クラウドベンダーが担保
- クラウド運用のセキュリティは大丈夫なの？ 自分たちで担保する必要あり。第三者の検証によりお客様の安心を頂く事が狙い
MSP運用する場合のSOC2対応は主に下記の二つ
- 障害対応
- システム 全てにおいてお客様・作業者・管理者にて証跡を残しています。
-
SOC2では必ず承認が必要 品質はあがるが、スピードは遅くなる
- SOC2では必ず作業をトレースできるようにログを残す 膨大なログの保管と調査可能な仕組みが必要 → 人的にもサーバリソース的にも多大なコストがかかる
下記の仕組みで人的コストを減らしている
- AWSコンソール作業 → 個人単位AMIでコンソールにログインしてCloudTrailにログを保存
- サーバ作業 → 個人単位OSアカウントにて踏み台サーバにログインし作業ログを自動でS3に保存
※：各ログインはLDAP認証で行い、ログインの前にBacklogへ課題番号の登録が必要
MSP運用で使っているツール
MSPセクションでは、様々なツールを使用しているそうです。
認証にPing Identity、監視にnagios/DATADOG/sensu、アラート管理にpagerduty、課題管理にBacklog、コンソール管理にadminpack（自社製管理ツール）、コミュニケーションにslack、作業予定・シフト管理にGoogle Apps、各種通知にhubotを使用しています。
実際にどのように運用しているのか
作業依頼・障害対応をwikiに掲載されている内容に従って、顧客連絡及び対応を行っています。
そんな簡単にいくわけありません！
cloudpackでは数百の案件、数千のサーバ（インスタンス）を運用していたりします お客様の要望には（基本的には）全て応えます！ まさにクラウドコンピューティングだからできる事です
運用
- 設計・構築運用がwikiに案件情報を記載 顧客情報、システム構成、障害対応手順 → 全ての情報を記載するのは難しい
- 運用中の顧客要望の変更 運用レベルの見直しはMSPにて対応 → MSPにて顧客調整も実施 顧客要望によるシステム変更 → 既存影響などあるため、設計・構築運用にエスカレーション
システム設計に関する考え方もMSPと設計構築で異なる
- MSPの希望 冗長化・バックアップなどがマネージドされているRDSを使ってほしい
- 設計構築の希望 処理速度や短時間フェイルオーバーを考えてEC2上にMySQLを構築してデータはエフェメレラルディスクを使用してMHAによる冗長化
※：当然お客様ありき。性能のみでなく運用負荷や障害復旧、データ消失のリスクを書くセクションの意見をもって提案しています。
アラート対応
- アラート連絡レベル
- アラート全部
- サービス影響あった場合のみ
- 一次対応の手順渡すので、まずは対応してほしい
- 連絡方法
- メールで連絡してほしい
- 電話してほしい
※：広範囲に影響が出ている障害時にシフト当番では厳しい場合もある。
脆弱性対応
- 連絡までは一斉通知で可能
- 個別の作業タイミングの調整 → 場合によっては夜間帯や休日の対応
- お客様の環境による前提の違い → 個別に調査・手順書の作成
※：お客様の規模により100台以上の規模のシステムもあれば1台でLAMP構成などもあり。 → 単純に構成管理ツール（ChefやAnsible）で対応できない
運用・アラート対応・脆弱性対応など多数のパターンがあるためMSPのみでは厳しい場合が多々あります。 セクション関係無く（人海戦術で）対応します。 影響時間外→担当に電話及びslackで全体通知
システム化できる部分はシステム化し、標準化できる部分は標準化します。（アラート検知の仕組み、定例作業簡易化など）
ただ、結局は 人の力に頼らざるを得ません
運用視点でのAWSサポートの利用Tipsの話
最後はAWSのサポートエンジニアである関山さんからAWSサポートのTipsです。
AWSサポートのご紹介
AWSに関する技術的なサポートを提供
- 1：1のタイムリーなサポートチャネル
- 経験豊富な技術サポートエンジニア
- 日本語での対応
- 24時間 265日 年中無休
- AWSの豊富なサービスすべてがサポート対象
AWSサポートの提供内容
- 対象内のもの
- AWSサービスや機能に関する問題解決支援
- AWSサービスや機能のご利用方法に関するQ/A
- AWSサービスや機能、運用に関するベストプラクティスのご案内（個別機能およびインテグレーション）
- [Trusted Advisor]などを利用したサービス利用効率化支援 *1
- サードパーティー・アプリケーションのサポート *2
- 対象外のもの
- お客様アプリケーションの開発、および、お客様作成プログラムのデバッグ
- お客様のシステム管理・運用・保守の代行
AWSサポートはお客様のEC2インスタンスへのログインは行いません
サポートケースの起票時ポイント
- 緊急度は"ビジネスインパクト"を基準に選択する
- 非常事態 → ビジネスが危機的な状況となっている
- 緊急 → ビジネスが深刻な影響を受けている
- 高 → アプリケーションの極めて重要な機能が損なわれている
- 普通 → 問題の一時回避が可能である
- 低 → 一般的な内容
- 調査に必要な情報を明記する
- 事象発生日時、発生頻度
- 影響範囲（調査対象のリソースを特定できる情報）
- ログ・画面キャプチャ（可能な限り省略しないで）
- 再現手順・再現コード
- 調査に必要な情報を明記する（Advanced）
- デバッグログ
- CloudTrailログ CloudTrailをあらかじめ有効化しておく！
運用をAWSサポート
ポイント
- AWS Support API
- AWS Trusted Advisor
AWS Support API
推奨事項をお知らせしてくれるサービス
Trusted Advisorのチェック事項
- コスト最適化
- パフォーマンス
- セキュリティ
- フォールトトレランス
Trusted Advisorを運用に活かす
- 手動：Trusted Advisorコンソールのダッシュボードをチェック
- 自動（週1回）：Tructed Advisorのメール通知機能をチェック
- 自動（任意のタイミング）：Support API経由でチェック
AWS Trusted Advisor
AWSサポートをAPI経由で利用可能
Trusted Advisorのチェック項目を確認する
背景：監視ツールで定期的にチェックしたい AWS CLIのコマンド例
$ aws support describe-trusted-advisor-checks\ --language ja\ --region us-east-1
※：取得頻度は1日に1回程度を推奨
イベント発生時にサポートケースを自動起票する
背景：監視ツールでイベント検知時にサポートケースを起票したい AWS CLIのコマンド例
$ aws support create-case\ --language ja\ --service-code "support-api"\ --category-code "general-guidance"\ --severity-code "normal"\ --subject "Test case"\ --communication-body "Test case. Please ignore."\ --region us-east-1
参考：Support API のテスト時のお願い Support API のためにテストケースを起票される場合は、下記の点にご協力 いただけますと大変幸いです。
- 件名および説明欄にテストケースである旨を記載する
- テスト終了後にクローズする
過去のケース履歴をエクスポートする
背景：サポートケースの履歴は、作成後12ヶ月間利用可能 AWS CLIのコマンド例
$ aws support describe-cases --language ja --include-resolved-case --region us-east-1\
--query "cases[].caseId[]" --output text | xargs -n 1 | xargs -I{} sh -c\
"aws support describe-communications --case-id {} --region us-east-1"
AWSサポートを活用して 素敵なAWS運用ライフを！
さいごに
AWSは頻繁にアップデートがあるあります。そのため運用のやり方もアップデートする必要があります。個人の力のみでそのアップデートに追随してくのは難しいので、Ops JAWSのような勉強会で知見を広めることが重要だと思います。 第１回目の勉強会でしたが次のイベントが楽しみですね。Ops JAWSの皆様ありがとうございました！
Ops JAWSの最新情報は[OpsJAWS] AWS運用管理コミュニティ メインページを御覧ください。 またTwitterアカウント（@opsjaws）もあるのでフォローしてみては如何でしょうか。
