以前、キーバンクは21のデータアイランドを抱え、問題の根本原因に対する可視性がゼロでした。反復設計でシステム全体をスケーラブルに作り変えた事例をご紹介します。

<p><em>本記事は2019年にシカゴで開催されたElastic{ON}ツアーの事例紹介セッションの要約です。ツアーのトークはアーカイブで多数公開中です。また、お近くの都市で開催される<a href="/jp/elasticon/">Elastic{ON}ツアー</a>のスケジュールも併せてご覧ください。
</em></p><em><p>キーバンクは、米国最大の銀行の1つです。事業の順調な成長に伴い、エンドツーエンドの監視システムの規模も拡大を遂げてきました。全米15州に1,100の支店と1,400台のATMを展開するキーバンクのインフラ設計は、いつのまにか“ノアの箱舟”になっていた、とクラウドネイティブ部門でシニアプロダクトマネージャーを務めるミック・ミラー氏は振り返ります。あるいは、“『なんでもふたつ』（訳注：中国の民話に基づく物語で、入れたものが2つになる“かめ”が登場する）にした結果、21のデータアイランドがあった”、とも描写できます。ミラー氏によれば、「平均復旧時間（Mean Time to Resolution）は非常に長く、平均炎上時間（Mean Time to Blame）は非常に短いという状態でした」。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt690471e02484a10f/5e15145312af1140b8e797f0/keybank-elasticon-overview-blog.jpg" data-sys-asset-uid="blt690471e02484a10f" alt="キーバンクのワークフロー" style="display: block; margin: auto;">
</p><h2>原因を探る</h2><p>以前のキーバンクでは膨大な数のシステムが稼働しており、サイロを横断してデータを手軽に相関付ける方法はありませんでした。したがって問題があっても、根本原因への可視性がゼロでした。各地の支店からは、ワークステーションのパフォーマンスの低さや、モバイルバンキングアプリのユーザー評価の低下に関する報告が寄せられていました。しかしオブザーバビリティデータを相関付けできない以上、担当チームにできることはありません。さらに悪いことに、同行のロギングとメトリックのシステムはストレージキャパシティの上限に到達しつつありました。新規の監視はすべて停止され、また当時利用していたサービスプロバイダーのライセンスをアップグレードする費用が高額すぎ、検討の余地もないことが判明しました。
</p><p>担当チームが監視リクエストの巨大なバックログ作りに着手すると、新規のシステムを開発する時間は失われ、さらに致命的な問題が浮上しました。パフォーマンスが原因で、顧客獲得機会損失が生じていたのです。たとえば見込み客が新規に口座を開設しようと試みても、システムは頻繁にクラッシュし、ラグが長く、ユーザーエクスペリエンスは非常に乏しい状態でした。口座開設が難しいと感じた見込み客は当然、別の銀行を検討します。
</p><h2>Elasticsearchでオブザーバビリティを強化する</h2><p>その頃キーバンクでは、セキュリティに関連しない場合、問題の調査に必要なログとメトリックをシステムから取得することができなくなっていました。そこで注目されたのがElastic Stackです。担当チームはElasticsearchの開発クラスターを立ち上げ、支店のネットワークにある何千台ものワークステーションにWinlogbeatとMetricbeatをデプロイし、ログとメトリックデータをインデックスし始めました。数日後、豊富なインサイトとともに、3つの根本原因が特定されました。ディスクI/Oが一貫して高い値にあること、利用可能なメモリが少ないこと、ネットワークが完全に飽和していること、の3つです。
</p><p>Kibanaで可視化したレスポンスタイムデータが多くの従業員の目に触れるにつれ、キーバンク内の危機感も高まりました。担当チームはシステム全体の更新という大仕事に着手する必要性を実感し、経営陣のゴーサインを得て最初の運用クラスターをデプロイしました。&nbsp;この結果、流入してきたオブザーバビリティデータにより可視性を得ることができたものの、同時に別の問題が発生しました。開発環境がクラッシュするほど、データストリームが多かったのです。こうして、スケールアップの必要性が浮き彫りになりました。
</p><blockquote><em>「悪いニュースもありました。ワークロードを正確に予測することは不可能でした。良いニュースは、変化の必要性を理解したことです。そこで新システムのアーキテクチャーは、ダウンタイムが必要なく、確実に再構築可能なデザインにしました」 — キーバンク、ミック・ミラー氏
	</em>
</blockquote><h2>“外科的”なスケーラビリティ</h2><p>その後も監視ニーズは増大し続けており、キーバンクは反復的なアプローチを活用してエンドツーエンドのシステムをスケールし、Elasticsearchの監視システムを進化させています。何度かの微調整を経て、システム全体に影響を与えることなく、“外科的”に変更を追加できるアーキテクチャーとするために、同行はいくつかの原則を確立しました。現在同行では、各論理ティアが次の条件を満たすことを要件としています。
</p><ul>
	<li>個別にスケール可能である</li>
	<li>高可用性である</li>
	<li>フォールトトラレントである</li>
</ul><p>これらはまさに、Elasticsearchと水平アーキテクチャーの得意分野です。&nbsp; 現在、同行でエンドツーエンドに投入し、インデックスを完了するまでのパフォーマンスは0.5秒未満です。0.5秒のSLAを満たさない場合、スケールアウトを実施しなければなりません。ミラー氏は、次のように語っています。「あらゆるデータが1か所に集まったことは、予定外のメリットでした。データの一元化に関して、Elasticsearchは本当にすぐれたソリューションだと感じます」
</p><p><a href="/jp/elasticon/tour/2019/chicago/how-keybank-used-elastic-to-build-an-enterprise-monitoring-solution"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt50073eabcf9a6db6/5e15167767e97c652d3c9617/keybank-elasticon-preso-blog.png" data-sys-asset-uid="blt50073eabcf9a6db6" alt="キーバンクによるElastic{ON}プレゼンテーションへのリンク" style="display: block; margin: auto;"></a>
</p><p>Elasticsearchシステムをスケールさせる方法についてさらに詳しくは、2019年、シカゴで開催されたElastic{ON}ツアーのトーク、「<a href="/jp/elasticon/tour/2019/chicago/how-keybank-used-elastic-to-build-an-enterprise-monitoring-solution">How KeyBank Used Elastic to Build an Enterprise Monitoring Solution</a>（Elastic Stackを活用したキーバンクのエンタープライズ監視ソリューション開発）」でご覧いただくことができます。またこのトークでは、同行が自動化を実装し、物理コンピューティングリソースと仮想化のバランスを調整して500万米国ドル以上を節約したエピソードも紹介されています。
</p></em>

Articles by Kasia Galazka

Elastic Stackを活用したキーバンクのエンタープライズ監視ソリューション開発

プロダクト

Elasticについて

情報