AWS運用専門の勉強会「Ops JAWS#1」に参加してきました #jawsug #opsjaws

Guri / Hajime Oguri

2015.09.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ウィスキー、シガー、パイプをこよなく愛する大栗です。 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（関山さん）

クラウド時代の運用エンジニアは何が変わるのか？

まずは、運用設計ラボの波田野さんの発表です。波田野さんのオンプレミス運用と運用自動化の経験を元に、今後の運用について「サービス」と「デリバリ」という２つの視点で発表していただきました。

2015-09-01 クラウド時代の運用エンジニアは何が変わるのか from Operation Lab, LLC.

オンプレミスとIaas、PaaS、SaaSを資産型と費用型という視点で捉え、サービス価値とデリバリ価値を重視した運用とは何か？を述べて頂きました。 Iaas、PaaS、SaaSの運用の中で「サービス価値」、「エンジニアリング価値」を考えると『サービス価値が無いと「運用」の存在意義がない』と断言されていました。自前主義の時代は終焉し、マネージドサービスの時代へ変化することで、優位性がないことや自前で出来ないことをマネージドサービスへ任せる必要が出てきました。

これからのインフラエンジニアは、一部のスーパーエンジニアはクラウドの中に行きデリバリ価値を提供し、大多数のエンジニアは上位レイヤーの独自性が求められる領域でサービス価値を提供することになるでしょう。

まとめ

あらゆることが根本的に変わる
カネが変わる
時間が変わる
やり方が変わる
サービス価値が無い「運用」は存在価値がなくなる
自前主義から、マネージドサービスの活用

なお、MSPは「真面目で凄いプロバイダ」、「丸投げサービスプロバイダ」の略のようですよｗ

cloudpack MSP運用の表と裏

cloudpack MSPセクションの新谷さんの発表です。

20150901 ops jaws_araya_v2 from Mitsuru Araya

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サポート利用Tips from Noritaka Sekiyama

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）もあるのでフォローしてみては如何でしょうか。