この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS re:Invent 2022にて公開されたセッション「 Using observability to build trust & improve incident response times (信頼性の構築とインシデントレスポンス時間の短縮のための可観測性(オブザーバビリティ)の活用) 」を聴講しましたのでレポートします。
本セッションは録画が公開されており、英語字幕を自動翻訳にて日本語で読むことが可能です。
Join this session with New York Life to learn about how they use New Relic’s observability platform to help engineers and DevOps increase self-service observability, improve incident response times, and build trust with their customers. This presentation is brought to you by New Relic, an AWS Partner.
(DeepLによる翻訳 : New York Lifeのセッションに参加し、New Relicの観測性プラットフォームを利用して、エンジニアやDevOpsがどのようにセルフサービスの観測性を高め、インシデント対応時間を改善し、顧客との信頼関係を構築しているかについて学びましょう。このプレゼンテーションは、AWSパートナーであるNew Relicによって提供されています。)
なお本記事は、DeepL翻訳ならびにYouTubeの自動翻訳機能による翻訳文字列を、一部あるいは全体的に引用しています。
また、レポートするにあたり話を要約したり、話の順序を一部変更したりしています、ご了承ください。
スピーカー
- Jordan Spiers
- Director of Alliances and Partner Marketing
- New Relic
- Mikhail Malamud
- General Manager
- Cloudaware
- Samuel Brinley
- Corporate VP / Enterprise Computing Services
- New York Life Insurance
内容
アジェンダ
- オブザーバビリティ(可観測性)のいま
- Cloudaware製品について
- エンタープライズ(大企業) + 可観測性
- ユースケースの紹介
- マネージドなDevOpsテクノロジー
- デモ : New Relic deployment challenge
New Relicの概要
- オブザーバビリティをシンプルに
- 全データを一箇所に、ひとつの予測可能な価格体系で
- 環境横断・目的指向の可観測性
- (New Relicのために管理すべき)ホストやアプリケーションは不要
- 可視化するエンジニア以外は不要
- 拡張可能
- 「オブザーバビリティの目的」とは？ なぜ可観測性を気にしなければならないのか？
- 運用視点とビジネス視点
- 観測可能にし、リアルタイムでトラブルシューティングをする
- 顧客体験を向上させ、高いレジリエントを持つアプリケーションを構築するため
- レジリエント = 障害からの復旧能力(意訳)
- 避けられないダウン状態から素早く復帰する --> ダウンタイムを短くする
- 観測可能である = コードとインフラストラクチャを「自信を持って」変化させることができる
- マイグレーションシーンの変化
- 単純な移行（リフト＆シフト）の時代は終わった
- 全てのケースに当てはめられるようなひとつの「何か」はない
- モダナイゼーション(近代化)、合理化
- ビジネスに重要なこと：
- 意思決定プロセスを早期に開始させること
- 全体像の把握・構築
- 最適にカスタマイズする（ワンサイズでは良くない）
- 単純な移行（リフト＆シフト）の時代は終わった
- Observable enterprise（可観測性に優れた大企業）
Cloudaware + New York Life
- Cloudaware
- CMDB(構成管理データベース)やコスト管理・変更管理などの統合運用管理SaaS製品、ならびにその提供企業
- AWS、Google Cloud、Azureに対応
- 参考 :
- New York Life Insurance
- 全米3位の規模を持つ生命保険会社
- 参考 : New York Life Insurance Company - Wikipedia
- 創業176年
- CloudawareとNew York Lifeの関係は10年以上前から
- New Relicを利用しつつ、New York LifeをAWSに移行した
- Cloudaware
- 在庫管理に関する機能を備えたクラウドオペレーションセンター
- 「CloudawareはITILの生まれ変わり(reincarnation)である」
- ITILを現代に合わせたもの・現代的にしたもの、という意味
- 重要な三つの要素
- Govern
- Integrate
- Automate
- Cloudawareに全てのデータを集める（データレイク化）
- CMDB
- AWS, Azure, New Relicのアウトプットを全て集めて統合
- 環境内で「何が起きているか」が把握可能
- ガバナンスやコンプライアンスの問題に対処可能
- インベントリ
- 採用状況
- インベントリの規模
- AWSアカウント数 : 500
- 総EC2 : 4,000近く（ただしEKSへ移行中）
- この規模（エンタープライズスケール）のインベントリに対処するには？
- 従来の手法では：
- New Relicのエージェントは全体の12%弱にしか導入できていない
- つまり：基本的に観測されていない可能性がある
- CloudawareがAWSとNew Relicの間を取り持つ
- AWSからインベントリの一覧を入手し、New Relicのエージェントが導入されているか確認する
- 含む：バージョン情報
- AWSからインベントリの一覧を入手し、New Relicのエージェントが導入されているか確認する
- CMDB（構成管理データベース）を中心とした情報統合
- New Relic : 可観測性とモニタリング
- Breezeモジュール, Puppet, Ansible : 構成管理
- RAPID7, nessus : 脆弱性情報管理
- PagerDuty, Jira : イベント管理
- ServiceNow : 脆弱性情報管理からイベント管理への連携・ITSM
- AWS, Azure, VMware(オンプレミス)
- Jamf（クライアント環境）
- 統合されたエコシステム
- AWS Health API
- インベントリ
- New Relicアラート
- インシデント通知フロー
- ステータスページ
- ステークホルダー(ビジネス意思決定者)が知りたがっていること
- 「何が起きているか？」ではない
- 「なにがどうなっていて、今は(彼らが)動くべきタイミングなのかどうか」を伝えるべき
- 「私たち(現場)が事態を把握しているかどうか」「ビジネスインパクトは」を知りたがっている
- 外部に説明するために必要な情報
- ステータスページ
- ↑Cloudaware DB
- ↑インシデント管理（PagerDutyなど対応状況）
- ↑New Relic
- ↑インシデント管理（PagerDutyなど対応状況）
- ↑AWS Health API
- ↑Cloudaware DB
- 例として：「2,3年前に起きたCognitoの障害」
- （おそらくこちらの件：AWSで障害--多数のサービスに影響 - ZDNet Japan
- AWSの障害が原因でRoombaが動かなくなりドアベルが鳴らなくなった
- これを契機に、New York Lifeは自身のサービスインフラの依存関係とビジネス影響の把握（サービス・マッピング）にのりだした
- どのように？ --> New Relicが収集したデータの調査
- Cloudaware上でAWSリソースと実際のアプリケーションとをマッピング
- 利用者はステータスページで状況を把握している
- --> ここに全ての情報が集まっている = 信頼を得ることに役立つ
- リソースに関するアラートだけでは十分ではない、「Enriched alert metadata（拡張情報が付与されたメタデータ）」が必要
- New York Lifeのアイディア
- 発生した事象がアプリケーションレベルのものなのか、SREチームが対応すべきものなのか、従来型の監視システムのアラート(閾値警告)なのか etc.
- インシデント管理システムで適切にルーティングさせることに役立つ
- アクション可能ではないアラート = 誤検知であると考えられる = ノイズを減らせる
- 将来的にAIOpsを導入する場合にも、この手のメタデータは有用
- 自動化(Automation)
- シフトレフト(Shift-Left) --> 従来型の運用モデルから、開発エンジニアがCI/CDを駆使して運用するモデルに移行すること
- --> 従来の「中央集権型の運用モデル」でやっていたことを自動化したい
- シフトレフト(Shift-Left) --> 従来型の運用モデルから、開発エンジニアがCI/CDを駆使して運用するモデルに移行すること
- Terraform Vending machine services (Terraform自動販売機)
- 開発チームが起動したリソースに対し、New Relicなど必要な共通サービスを組み込むためのIaCコード
- セルフサービスの時代
- セルフ = 開発エンジニアが自分たちで
- 中央集権的な運用モデルでは、この規模のリソース群を相手にするには不向きである
- 各自が自分たちで何か出来るようにしないととスケールしない
- Cloudaware Breezeが適切にNew Relicエージェントの対応OSやアーキテクチャを判断
- 基本的に監視設定やアラームをコードで構成（IaC）
- Terraformを使うことでNew RelicとAWSのインテグレーションを構成できる
- newrelic/terraform-provider-newrelic: Terraform provider for New Relic
- Docs overview | newrelic/newrelic | Terraform Registry
- New Relicはいち早くTerraform対応を始めた
- コードによりいちから構築でき、細かくコントロール出来る
- 「このことこそ、CloudawareがNew Relicのパートナーである理由である」
デモンストレーション
- Terraformを用いたNew RelicとAWSの連携
- 何を監視して何を監視しないか？
- 理由 : コストへの影響
- 監視すべきサービスの選択
- リソース単位でフィルタリングも可能（リージョン、オーナー ...）
- コードで管理可能
- --> 中央集権的な運用チームに依頼する必要は無い
- 何を監視して何を監視しないか？
- New RelicのアラートもTerraformで設定
- プルメソッドとプッシュメソッド
- プル : CloudWatch API
- プッシュ : Kinesis --> CloudWatch MetricStream
- リアルタイムにストリーミングされる
- APIコールに対して課金されない
- 収集するデータの種類を(New Relic側で)選択できない
サマリー
- 重要なこと
- 信頼を得ること
- ステークホルダーに全てを知らせること
- 統合する
- 全てを観測するために
- 自動化
- 現代の規模では必須
- 信頼を得ること
まとめ
「大企業は保守的で、最新技術へのキャッチアップが遅いもの」という、漠然としたイメージがつきまといがちではありますが、それを覆すようなセッションでした。創業176年、全米第3位という規模を持つ老舗の生命保険会社でありながら、10年前からクラウドへ移行し、数百数千の保有システムの大部分において可観測性を確保していて、「大企業だからこそ高い可観測性が必要なんだ」というメッセージを発していたのは、ある種痛快でもありました。
また、「IaCこそが鍵」というメッセージも印象的でした。New RelicをTerraformで全てコントロール出来るというのは、（素晴らしい特徴ではあるものの）これまでそんなに強調されるものではなかったと思います。しかしここでは、それがあることでこの規模に対応出来たこと、目的に合致していたことが強く発信されていました。
51分と録画セッションにしては長めで、かつ終止Cloudawareの担当者が若干よくわからないテンションだったのが気になりますがｗ、大変興味深い事例セッションだったので、ぜひ英語字幕＋日本語自動翻訳をONにして聴講してみてください！
3
