オブザーバビリティ
ソフトウェアとテクノロジー

Box: Elastic Stackで実現した可観測性の向上

数字で見る

  • 1800億
    Elasticsearch内のドキュメント数
  • 190TB
    総データサイズ
  • 20TB
    投入レート(1日あたり)

コスト削減

SplunkからElastic Stackへの移行で、ログのデータ投入費用が半減

可観測性の向上

データ投入費用を理由にログ分析プロジェクトを断念する必要がなくなった

エンジニアを支援

Box社の成長に伴い、ログ分析プロジェクトを広げ、可観測性を向上に貢献

Boxについて

ストレージプロバイダーのBox社は、クラウドコンテンツマネジメントプラットフォームを主力製品としています。社員や顧客の生産性向上をサポートすると同時に、各種ファイルからミッションクリティカルなワークフローまで、貴重なデータを保護するサービスを提供しています。

現在、クラウドコンテンツマネジメント分野の市場競争は激化しています。Boxは、かつてないスピードで問題を早期に検知、特定して解決することを何より重視しています。同社は顧客企業のミッションクリティカルなワークフローを数百万件もサポートしており、安定性とパフォーマンス、コンプライアンスに関する厳格なSLAを提供する必要があります。

このSLAは、わずかな問題でも顧客企業側からサービスを解約できると定めています。こうした背景から、Boxは9万5千社もの法人顧客と、何百万人ものユーザーを抱えるインフラへの明瞭な監視性を必要としています。

同社で監視チームの技術マネージャーを務めるディーパック・ワドフワニ氏は次のように説明します。「お客様はBoxを信頼して、ビジネスクリティカルなワークロードやコンテンツを預けてくださっています。万が一Boxが正常に動作しなければ、お客様にとってはまぎれもない収益損失となります」

同社のWebサイトには、オールステート保険やアストラゼネカ、ザ コカ・コーラ カンパニー、モルガンスタンレー、オックスファム、オリンパス、パンドラ など、名だたる顧客が並んでいます。

BoxのElastic Stackストーリー

Elastic Stackの箱を開いて

Boxの技術チームはここ数年、レポートに使われるレガシーのバックエンドがスケーラブルでないことに懸念を抱いていました。同社のロードマップが成長シナリオを描く中、監視チームはSplunkによるアプリと運用のロギングに代えて、高い信頼性とコスト効率を備えたソリューションの検討をはじめました。

一方、さらに重要な課題として、社内ではミッションクリティカルなプロセスが進行中でした。同社は、成長とイノベーション、また顧客向けの新機能の導入のため、一体型のインフラから数百のマイクロサービスへと移行する途上にありました。

以前Boxが採用していたロギングソリューションは、投入するデータ量に応じて費用が発生する仕組みでした。そのため、コスト削減のためにロギングプロジェクトをカットしたり、新規にデプロイしたマイクロサービスから来るイベントのロギングをあきらめるなどの判断に追い込まれる場面もありました。

それは、クラウドコンテンツマネジメントの代表的プラットフォームへと急成長を遂げるBoxが掲げるミッションの方向性と一致するものではありません。さらに一体型から数百のマイクロサービスへとインフラを移行させるにあたり、より包括的なロギングが必要となりました。ロギングを"減らす"という選択肢もありませんでした。

"以前は、コスト削減のためにロギングのデータ量を削る必要がありましたが、Boxをより観測可能なシステムにするという私たちのミッションとは矛盾していました。本当に必要だったのは、よりコスト効率に優れ、かつ可視性というミッションを達成できるシステムを構築することだったのです。それがElasticのソリューションを選んだ理由です。開発者の開発作業に役立つよう、設計されたソリューションです。"

– ディーパック・ワドフワニ, 監視チーム、技術マネージャー | Box

さらに同社では、エンタープライズレポートに使用されていたMySQLに関して別の問題が生じていました。最大の問題は、大規模企業でファイルを開く、別のフォルダへ移動する、共有するといった使用状況のログデータを生成できないことでした。常時大量のイベントが生成されているためです。

そこで2015年、価格や拡張性、サポート、セキュリティといった点から複数の候補を調査した後、BoxはElasticのソリューションを選択しました。

Boxは、将来にわたり有効で、スケーラブルな監視性のアプローチをElastic Stackで実現しました。費用は投入するデータの量ではなく、管理するメモリーのサイズに応じて生じる仕組みです。Elastic Stackへの移行でBoxのレポート機能は強化され、コストは劇的に軽減しました。またBoxのマイクロシステムからログを収集し、パフォーマンスや挙動を把握することも可能になりました。ログは収集と同時に、すぐ活用することができます。

レポート作成のユースケースは、Box社がElasticのソリューションを活用するきっかけとなりました。MySQLからの移行に成功すると、Elastic Stackへの信頼と確信はより深まり、その結果、新たなマイクロサービスとしてElasticのロギングソリューションへ移行することが決まりました。

新しいレポートとロギングのシステムが社内エンジニアの支持を得られなければ、プロジェクトの成功は呼び込めず、導入作業も速やかに進めることはできません。Elastic Stackを選択したBoxの社内では、現在多数のエンジニアが積極的に大規模なレポーティングを実行するようになりました。新規と、既存のマイクロサービス向けのロギングも実装され、結果として市場におけるBoxのプレゼンスもますます拡大しています。

"エンジニアは快適に作業できるようになり、クエリも瞬時に返されます。Boxの顧客満足度指数も大幅に上昇しています。"

– サルマン・アフメッド, データプラットフォーム&監視SREチーム、技術ディレクター | Box

Boxで当初Elastic Stackを使いはじめた際、関与したのはストレージチームに所属する数人の開発者だけで、ストレージもわずか数テラバイトの規模でした。新しいレポーティング機能の開発と導入には、Elasticコンサルタントによるオンサイトのサポートや、トレーニングコースのセッションも活用されました。現在同社では、多数のチームにわたり500名ものエンジニアがレポーティングやロギングにElastic Stackを使用しています。また数百種類のKibanaダッシュボードで、日々テラバイト規模のデータが可視化されています。

プロジェクト「ニュースルーム」

BoxがElastic Stackを導入した最初のユースケースは、エンタープライズログをレポーティング用にElasticsearchに移行し、バックエンドでデータ分析に用いるというものでした。そのデータパイプラインは後に改良され、現在はElastic Stackによる新しいロギング環境が構成されています。

またレポーティングのプロジェクトでは、ロールベースのアクセス制御やユーザー認証など、Elasticのセキュリティ機能も最大限活用されています。この他にも、「Boxにあるファイルに、いつ、どこで、誰がアクセスしたか」を通知するなどの機能を搭載したことで、Boxはセキュリティやプライバシーを含む各種のコンプライアンス義務を満たすサービスとなりました。

レポーティング用にElasticsearchへと移行するプロジェクトが立ち上がった頃、社内では「ニュースルーム」というコード名が使われていました。「ニュースルーム」はエンタープライズログとビジネス分析に関するフィルタリングや、整合性の問題解決のためのプロジェクトでした。レポート生成に関する問題が発生しなくなれば、SLAも満たすことができます。Elastic Stackの導入前、大規模な法人ではレポートを読み込むことができないといった問題が、中規模法人ではレポートが返されるまで時間がかかりすぎるといった問題が生じていました。

その他の改善

  • ユーザー/フォルダーの使用状況ログを効率的にフィルタリングする機能を追加
  • 組織または特定のフォルダー内で特定のユーザーに関するイベントを取得する機能を追加
  • 管理者コンソールに表示される統計レポートの安定化
  • エンタープライズログとビジネス分析の整合性の問題を解決

「Arta」の開発

以前Boxが使用していたロギングソリューションはデータ投入に応じて費用がかかる仕組みで、当時1日あたりの投入量は約7テラバイトでした。現在は1日あたり約20テラバイトを投入し、今後も投入量は増える見込みです。破滅的なコスト増を防ぐためには、成長し続けるマイクロサービスプラットフォームの中で、監視機能を実装する部分を取捨選択する必要がありました。Elasticのソリューションに切り替えなければ、いずれ行き詰まりを迎える課題です。

さらに、問題はコストだけではありません。当時のロギングプラットフォームでは、インデキサーにエラーが生じることがしばしばありました。レイテンシーもあり、アラートの信頼性も今一つ、という状況でした。

"スケールを重ねた5年間、これはどういうことだろうと考え続けていました。Elastic Stackに切り替えたことで、1テラバイトあたりのコストは半分になり、マイクロサービスを構築する開発者により快適な毎日と優れた監視環境を提供できるようになりました。コストを理由にロギングをあきらめることもなくなりました。"

– ディーパック・ワドフワニ, 監視チーム、技術マネージャー | Box

こうした状況と日々ロギングするデータ量の増加を鑑みて、Boxは2017年にロギングインフラを再構築しました。

同社はリテンション/アドホック/インタラクティブの3つの異なるアプローチを併用し、すべての運用とアプリのロギングを継続的にElasticsearchに安全に移行しています。このパイプラインは、社内でAlmost-Real-Time-Analytics(ほぼリアルタイムな分析)、あるいは「Arta」というコード名で呼ばれています。

ミッションクリティカルなビジネス機能

Boxにとって、エンタープライズグレードのシステムを運用・保守し、またSLAで保証するパフォーマンスを保つことは何より重要です。したがって同社のエンジニアには、自社システムと、そこで生成されるログの可視性が不可欠です。アフメッド氏によれば、Elastic Stackを使ったロギングシステムは、最小のインデキシングオーバーヘッドで高度なクエリ機能を監視チームに提供しています。また、スケールも安価だといいます。

"Elastic StackはBoxにとって不可欠な存在です。世界中で、何百万という顧客やユーザーがBoxを信頼し、日々ミッションクリティカルなビジネス機能を実行しています。Elasticsearchのおかげで、Boxの監視チームは高い安定性と、コスト効率を誇るロギングシステムを構築することができました。"

– サルマン・アフメッド, データプラットフォーム&監視SREチーム、技術ディレクター | Box

Elastic Stackが実現する可観測性と、そのデータをKibanaで可視化する数百ものダッシュボードにより、Boxのエンジニアはデータインサイトを思いのままに利用することができます。エンジニアは顧客がBoxのファイルを開く際に問題が生じたとか、あるいは共同作業者がファイルを追加した、ファイルがフォルダーに追加された、名前が追加された、といったことまで確認することが可能になりました。ログの活用で、顧客によるファイルのアップロードに生じる遅延など、各種問題の根本的な修正をすばやく行うこともできます。すばやい修正は、アップタイムSLAの要件を満たすために役立ちます。

同社のストレージチームは、重要なビジネスワークフローを担当しています。Kibanaのダッシュボードは、ファイルサイズを問わず、アップロードされるファイルの種類別や、使用されたWebクライアント別にアップロード状況のアグリゲーションを可視化してストレージチームに知らせます。

Boxで上級エンジニアリングディレクターを務めるデイブ・ワード氏は、優れたユーザーエクスペリエンスを継続的に実現するには、コード変更に確実に責任を持つためのロギングが重要だと語ります。

「機能の追加や修正のために変更を加えたとき、『変更によって望ましい結果がもたらされたか?』を 確認しなければなりません。コードをプッシュする際には『エラーがないか?』確認します。意図したとおりに監視パイプラインが動作しなければ、システムの健全性を保証することもできません。サービスの敏捷性を保ちながら、コンスタントに大規模なリリースを保つ上で、Elasticsearchを活用したArtaが何より重要です

BoxのElastic活用ロードマップ

現在Boxでは、Artaで開発者向けに大規模な運用レベルのロギングストリームを実行するプロセスが進行中です。開発中のマイクロサービスから既存、および新規のロギングストリームを継続的に追加しながら、同時に安定性や回復性、運用効率のさらなる向上とコスト削減も図っています。

Boxでは今後、Elasticのソリューションを活用してさらに多くの追跡メトリックを1つのプラットフォームに集約することも検討しています。Elasticのエンジニアとも積極的に連携し、プロダクトの改善やフィードバック提供にも協力しています。

さらに、Elasticのアプリパフォーマンス監視ソリューションであるElastic APM機械学習を活用した問題検知とアラートや、地理的IPマッピング機能でIPアドレスを活用し、クエリの送信元を世界地図上で可視化する取り組みにも関心を寄せています。

またElastic SIEMによるセキュリティ運用や、Canvasを使ってKibanaで美しいダッシュボードを作成する取り組みなど、Elasticが提供する豊富なオプションの活用を模索しています。

費用対効果

費用対効果としては、Elastic Stackの導入により、投入データ量の費用が半減しました。さらに、MySQLを使用していた時に生じていたレポーティングの問題も解消されました。以前、schema on read方式のロギングソリューションで部分的に生じていたレイテンシーも、Elasticのschema on writeに変わったことで過去のものとなりました。

ワドフワニ氏は、レイテンシーがもたらす困難について次のように説明します。「以前はお湯を沸かすために海を沸騰させよう、というような、無駄なやり方でデータを 取得しようとしていました。ElasticsearchとKibanaなら、クエリも迅速です」

また、数字で捉えられない部分でも変化は起きています。現在Boxはエンジニアに対し、エンタープライズグレードのプロダクト構築に必要となる水準の監視性を確立するため、適切な量のログを収集することを積極的に促しています。

このような方針の変化は、Boxが社内外のSLAを満たす手助けとなっているだけでなく、成長を目指し、開発者にイノベーションを働きかける土壌作りにも貢献しています。

Boxがデプロイしたクラスター

  • クラスター数
    1
  • ノード数
    データノード:85、マスターノード:3、クライアントノード:6
  • LS/Beatsインスタンス数
    Logstash×20
  • ドキュメント総数
    1,800億
  • 総データサイズ
    190 TB
  • 投入レート(1日あたり)
    20 TB
  • インデックス数
    250
  • クエリレート
    25クエリ/秒
  • 複製
    1
  • 時系列インデックス
    日ごと
  • ノードの仕様:メモリー(トータル/CPU/ディスクタイプ;SSD/HDD)
    AWS i3.4XLarge