【レポート】見えないお客様を知ることから始める、デジタルトランスフォーメーション成功の為の方策 #AWSSummit

こんばんわ、札幌のヨシエです。 AWS Summit Tokyo 2019 初日のG1-01で行われたセッションのレポートを書きましたのでご査収頂ければと思います。

登壇者

New Relic株式会社 シニアソリューションコンサルタント 日吉 潤一郎

デジタルトランスフォーメーションを成功させるためには、複雑なシステムをハイスケールに保ち、そして、お客様に優れたユーザー体験を提供し続けることが必要とされています。 分散化が著しく進む今日、その実現に課題をもつ企業が多く存在します。その解決の鍵と考えられているのが、オブザーバビリティ（可観測性）です。 本セッションでは、オブザーバビリティ プラットフォーム New Relic を利用することで、それらの課題をどう解決できるのか、お役立ていただける方策をご紹介します。

最初に

2021年までに少なくとも50%グローバルGDPはデジタル化される(IDC)

ZOZOスーツの登場

• デジタルビジネスの世界で大きいインパクトを与えた
• ZOZOTOWNはNewRelicのユーザーであり、
• デジタルトランスフォーメーションで成功するにはリスクを測定してサービス展開を行う必要がある

デジタルビジネスにおけるリスクとは？

• 実店舗であれば「何を探しているのか？」「細かいお客様の反応」や「ディスプレイに対する反応」などお客さんの動向を観察することが出来る
• また、ミスや失礼といった感覚面を感じる事が出る
• デジタルではユーザーエクスペリエンスが成功するにあたって重要なポイントとなる
• 並行して様々なエラーなどを観測することが出来るので改善に繋げられる
• しかし、リスクが見えないこと状態でサービス展開に対する恐怖心が勝ってしまい、着手のハードルが高くなる

MLB Advanced Media様のNewRelic利用事例

上記の点をNewRelicを用いて解決につなげたのがMLB Advanced Media様の事例である

• MLB Advanced Media様がNewRelicユーザーであり、デジタルビジネスを意識した構成となっている
• MLB Advanced Media の導入事例
• さまざまなデバイスで広告やオークションなどの様々なビジネスを展開している
• 担当者のコメントからも非常に高い効果をもたらしたものと見受けられる
• 「New Relicがあればユーザー体験の質を損なうことなく、開発者が実験を行うことも作業を迅速に行うことも可能です」
• これはエンドユーザーがどういうことに着眼点を持っているのかを把握良い例となっている

MLB Advanced Media様の事例では、NewRelicを使用して3つのミッションを解決した

ミッション：UX(ユーザーエクスペリエンス)を測定せよ

• サービスのアベイラビリティ(可用性)を測定していることを指す
• スループットやメモリ使用率ではなく、「サービスが利用できる状態であるのか？」を測定している
• 100%のユーザーが使える、使えなくなるではなく、サービスによって「どのような機能が利用できるか」に着目することでユーザーエクスペリエンスの測定を策定した
• また、過去の傾向を把握することで次回の教訓として事前対策を打つことが出来る(例として、定期的なイベント等による負荷であればスケール対応など)

具体的な測定面

具体的な測定項目例は以下のようなものを測定している

• Webショップ(ECサイト)
• 重要な操作(購入手続きなど)のページ動向を数値で測定
• 「Webショップ(ECサイト)の購入手続きがどこまで進んでいるのか？」といったをリアルタイムで監視
• 受注件数や受注額、失注数などをビジネス要素の数値面を監視基盤であるNewRelicを用いて可視化
• オークション
• 現状の商品に対するBit総額
• 入札金額
• 野球中継(動画配信)
• 動画視聴傾向
• 再生動画のビットレート
• 動画の視聴ユーザー情報を可視化
• 時間帯別、ブラウザ、アクセス元市町村といったカテゴリー集計
• 動画バッファリング時間の測定
• ユーザー離脱数
• 広告の視聴状況

BIツールとNewRelicによる測定の違う点

• 同様のアプローチを実現する点で、BIツールを利用する事がある
• これは実店舗で得られたデータをDBに投入し、ビジネス数値や分析手法を用いて可視化を行う
• しかし、現在はビジネス展開モデルを考え見てアプリケーションからリアルタイムで情報を抜き出し、可視化していることが多いとのこと

実際の活用による所感

• ユーザー操作はフロントエンドだが、裏では多くのバックエンドが複雑に連動している
• 状態が見えない状況を可視化することでビジネスチャレンジにつなげる
• 例えばユーザー増が発生した場合、フロントエンドと密接に関係するバックエンドととも複雑に連動している
• そこで何か問題が発生した時は「アプリサーバーへのアクセス後、他にどういう影響が出ている」、「アプリケーションじゃなくてバックエンドが遅いのでは？」といった複数のバックエンドが懸念点として挙げられることがある
• この点を後述するサービス全体の測定によってクリアにした

ミッション：すべてを測定せよ

• observability(可観測性)
• 由来として、マイクロサービスの分散トレーシングの文脈から生まれた言葉で欧米では急速に広まっているワード

これまでの監視

• これまでの監視方法は監視対象ホストの起動時間とライフサイクルの長さが起点となっている
• 以下は平均的なホストの起動時間のイメージとなる、物理サーバーは年(月)単位で起動しており、ホストが対象外となるコンテナや関数になることで分(秒)単位の起動時間となる
• 物理サーバー ＞ 仮想サーバー ＞　クラウドVM　＞　コンテナ　＞　関数(serverlelss)

• これまでの監視では起動時間を元にホストの稼働状況を取得して可視化していた

• 物理サーバーのCPU使用率を例とすると、時間単位から分単位で稼働率を観測出来ている
• コンテナや関数ではタイミングが秒単位でライフサイクルも処理開始後の数秒で停止又は終了するので非常に早い短いライフサイクルであることからサンプリング値が高低にムラが見えてしまうことがある
• 上記の観点と市場の動向をから従来型の監視(定点監視)では限界に近づいている

これからの監視は？

• 今後は監視対象の測定方法をは固定から動的に変化
• 定期的メトリック収集を実施→対象のイベント収集

• 時間軸上での比較 → 対象間の依存性(コンテクスト)

• この点をクリアするためにNewRelic Oneという可観測性を考慮したプラットフォームを利用することが次の監視の可能性につながる

• これはサービス全体のシステム構成要素(DBやモバイルアプリケーション、コンテナなど)をエンティティとして捉え、様々な依存関係を集約して影響度を可視化することに努めている

• 例として以下のような依存関係があるとする

• これはLambdaで構成されているサービスとしてろい、Lambdaから別のLambdaを呼び出すことによる処理時間やボトルネックを洗い出すことが出来るものとなる
• この可視化が実現することで関係するサービス間の影響度やレスポンス/スループットといったUXに関わる様々な値に具体性を持たせる事ができる

サービス --- Lambda --- Lambda ---Database
|--- Duration(外側の処理やDBアクセスやそれ以外の処理を分類して経過時間を計測できる)
|------- ColdStart
|------- invocation(関数実行時の各ステップを出力)
|------- その他メトリック情報(Lambda関数実行時のエラー総数やエラートレース結果)

ミッション：デジタルトランスフォーメーションをドライブせよ

• ビジネスの存続や価値の数値の可視化に向けた動き
• 以下のような数値の可視化が実現できる
• アクセスユーザー数比較や時間ごとの売上推移
• エラー影響を受けたユーザー数、エラーの影響を受けた販売上限
• 現在のAWS利用コスト
• 利用傾向やインスタンスタイプは？インスタンスステータスなどなど
• DevOpsでリリースサイクルを可視化出来る
• コミット回数
• リリース回数
• テストの成功回数 vs 失敗回数

最後に

非常に多くの機能を有するNewRelicに関して事例を交えたわかりやすいセッションでした。 個人的にインフラ環境は物理/仮想サーバーからコンテナやLambda関数にシフトしている面で 監視方法が異なる点とビジネス面の数値化に視点が広がっているように感じておりましたので 腑に落ちるお話でした。

ぜひ皆様も扱っているサービス監視を見直すことでビジネス改善の鍵に見つかるかもしれませんので、これをいい機会として監視面の見直しをご検討されると良いかと思いました。