SAP Concur：DevOps戦略としてのElasticロギング

この投稿は、2018年のElastic{ON}で行われたコミュニティトークのまとめです。これらのトークはアーカイブで多数公開中です。また、Elastic{ON} Tourが近くの都市で開催される時期もご確認ください。

経費精算書を入力したことがある方なら、おそらくSAP Concurの使用経験をお持ちでしょう。150か国以上（Fortune 500企業の70%を含む）で4,500万人以上のユーザーを抱えるConcurはトップクラスの出張経費管理ソリューションです。このSaaSサービスは、2016年だけでも870億米ドルを超える経費を処理し、これは毎日240万件以上の領収書と1億8,700万米ドルの請求書が発行されたことを意味します。会計担当者にとっては膨大な項目数に思えるかもしれませんが、ログ記録ソリューションにとっては、日々処理しなければならないログ項目がさらに増えることになります。

Concurは20年以上にわたり事業を展開しており、製品ラインナップの拡大と進化に伴い、ログソリューションも進化を遂げてきました。使用するテクノロジーだけでなく、その利用範囲と目的も変化しています。当初はシンプルなログストレージにSQLベースのソリューションを使用していましたが、現在ではElastic Stackを基盤としたログソリューションにより、エンドツーエンドのアプリケーション所有権を促進し、開発、テスト、運用を連携させています。さらに将来的には、ConcurのLAMA（ログ記録、アラート、モニタリング、分析）チームは、Elasticの機械学習を活用して運用分析やインサイトを取得するとともに、ロールアウトとロールバックの自動化も計画しています。同社はロギングにおいて大きな飛躍を遂げてきましたが、ログストレージから分析へと一夜にして到達したわけではありません。

ログソリューションは当初リレーショナルデータベース上に構築され、RabbitMQを介してXML形式でログデータを取り込み、ユーザーはSQLを使って簡単にログを検索できることを好んでいました。しかし、サービスの人気が高まるにつれて利用量も増加しました。ピーク時の取り込み量は1日あたり200GB、毎秒1,500件以上のドキュメントに達し、サービスは限界に達しました。パフォーマンスの遅延により、ユーザーはログがシステムで利用可能になるまで最大20分待たされることもありました。ログチームができた対応策はデータベースをより高性能なハードウェアに移行することだけで、これは持続可能な方法ではありませんでした。必要だったのは水平スケーラビリティであり、そのためにより良いソリューションを探し始めました。

Elasticsearchを調査し、同じような状況にある企業のさまざまな成功事例を確認した後、ConcurはログソリューションとしてElastic Stackを選択しました。高速で、パワフルで、拡張性に富み、そして（おそらくそれ以上に）社内ユーザーにとって重要なのは、ユーザーが好む可視化コンポーネントを備えていました。以前は、さまざまなチームが独自のインターフェースとダッシュボードを構築していましたが、多くの場合、業務をこなすために使用する必要のあるツールのライセンス料が発生していました。Kibanaのおかげで、Concurは統一された可視化ソリューションを手に入れ、自社開発またはサードパーティの可視化ソリューションが不要になりました。

Elasticの最初の実装は、Elasticsearch 1.1とKibana 3を使用し、取り込みはLogstash、RabbitMQ（SQLソリューションで使用していたものと同じ）、Fluentdから行われました。ログチームは、Elasticのオープンソースの性質の恩恵を受けて、独自に開発したアラートプラグインを構築することもできました（Elastic Stack内にはまだ存在しなかったため）。Elasticsearchの速度向上、Kibanaの可視化機能、そして自作のWatcherプラグインのアラート機能により、Concur全体でのサービス採用が増加し、取り込みは5,000ドキュメント/秒に急増しました。SQLソリューションでは到底対応できなかった規模です。

Elasticを使ったソリューションから戦略への成長

その最初の実装以来、ConcurのロギングソリューションはElastic Stackとともに成長してきました。2015年にはElasticsearch 2.3とKibana 4.5にアップグレードし、ゴールドサブスクリプションを購入し、Beats（Fluentdの代替として）、Watcher（自社開発のソリューションの代わりに）、Shield（セキュリティ用）を使い始めました。また、別のカスタムプラグイン、今回はカスタムアグリゲーションUIも構築しました。ロギングソリューションが向上するにつれて採用率も向上し、2017年までに取り込み速度は最大60,000ドキュメント/秒（4TB/日）に達しました。

Elastic{ON} 2017に参加した後、Concurは再度アップグレードしました。今回は、クラスター横断検索、セキュリティの強化（GDPRコンプライアンスを確保するために必要）、カンファレンスで学んだその他のElastic Stackのオプションを活用するためです。クラスター横断検索を使用して、モノリシックなクラスターを複数の地域にまたがる複数の小さなクラスターに分割することができました。このバージョンのアップグレード（とプラチナサブスクリプションへの移行）は、さまざまなインジェストソース、複数の地域にまたがるElasticsearchクラスター（米国では5TB/日）、運用、SRE、サポート、経営幹部などが使用するKibanaのダッシュボードなど、現環境の確立に役立ちました。そして、それらはすべて6人のエンジニアと2人のマネージャーで構成されるLAMAチームによって管理されています。

Concurがどのようにしてログストレージから所有権の有効化に移行したかについては、Elastic @ SAP Concur：DevOpsとエンドツーエンドの所有権への道のりの推進をElastic{ON} 2018でご覧ください。また、ワンクリックでのロギングサービスの導入方法、200以上のチームに対するマッピング（非動的）とフィールドの設定方法、そしてElasticの機械学習の力を活用する計画についても学べます。