ECEのおかげで、操作性が高く経済性にも優れたログの収集・活用の サービスが実現され、プライベートクラウドの価値が高められました。
ECEのAPIが充実しているおかげで、Elasticsearchクラスター活用の セルフサービス化が実現され、およそ0.1人月でElasticsearchインフラの運用管理が回せています。
KADOKAWA Connectedについて
株式会社KADOKAWAの戦略子会社として2019年4月に設立された KADOKAWA Connectedは、日本最大級の動画サービス「ニコニコ(niconico)」をはじめ、KADOKAWAグループにて運営するサービスのインフラ開発・運用や、ICTコンサルティング、働き方改革支援を手掛け、その実績を活かしたデジタルトランスフォーメーション (DX)アドバイザリーサービスを提供しています。大規模なインフラ、ネットワーク、ビッグデータ分析をサービスとして提供しながら、企業のDX実現も手がけ、各分野の先端を走るビジネスパートナーとともに実行しています。
Webサイト：https://kdx.co.jp/
Twitter：https://twitter.com/KADOKAWA_KDX
有力クラウドに対抗しうる機能の提供と業務の属人化を阻止するために
KADOKAWAグループのDXを推進しているKADOKAWA Connected。同社には、KADOKAWAの情報システム部門をはじめ、2014年にKADOKAWAと経営統合した株式会社ドワンゴの情報システム部門、有料会員150万人強の動画サービス「ニコニコ動画」「ニコニコ生放送」といった商用サービスのインフラチーム（サービスインフラチーム）、さらには、データ分析の専門チームが統合されており、経営陣も含めて社員の多くがITエンジニアという特色を持つ。
そうした同社のサービスインフラチーム（KADOKAWA Cloud Service部）では、ElasticsearchやKibanaなどのプロビジョニング／管理／監視を単一のコンソールを通じて行えるElastic社のサービス「Elastic Cloud Enterprise（以下、ECE）」を活用し、KADOKAWAグループに向けたプライベートクラウドサービス「Elastic Stack as a Service（以下、ESaaS）」を展開している。
ESaaSはもともと、「ニコニコ動画」に関わるログの検索・収集・格納プロセスを簡素化することを目的に、KADOKAWA Cloud Service部がドワンゴ内にいた当時（2017年ごろ）に作られた。
その経緯について、KADOKAWA ConnectedのKADOKAWA Cloud Service部部長の加藤俊弥氏は次のように説明する。
「私たち（サービスインフラチーム）にとっての“顧客”は、ニコニコ動画の事業部など、KADOKAWAグループ内の事業部であり、“競争相手”は、主要なクラウドプラットフォームプロバイダーです。2017年ごろ、それらの競合相手のプラットフォームを調査したところ、私たちのサービスインフラに足りていない仕組みの一つとして、ログなどの非構造化データを検索・収集・格納するためのNoSQL型データストアが浮上しました。それが、Elasticsearchの導入を検討し始めたきっかけです」
また、 Elasticsearchの採用を検討し始めた背景には、ドワンゴ内でのエンジニアの流動性を高めようとする会社の方針もあったという。
「2017年ごろのドワンゴでは、入社したエンジニアが、長く同じ仕事に携わるケースが多く、業務の属人化が進行しつつありました。それを問題視した当時のドワンゴのCTO（最高技術責任者）が、エンジニアの流動性を高めて個々人によるキャリア選択の幅を押し広げるという方針を打ち出しました。そのこともElasticsearchに対する私たちのニーズを膨らませた一因と言えます」
例えば、ニコニコ動画とニコニコ生放送といったサービスごとに、ログの検索・収集・格納に使う技術が異なれば、エンジニアは担当するサービスが変わるたびに新しい技術の使い方を習得しなければならず、人材の流動性は高められない。その問題を解決するには、ログ検索・収集・格納の仕組みも、単一のソリューションで標準化・共通化を図る必要があり、Elasticsearchはそれを実現するのに適した技術だったのだ。
こうして、サービスインフラチームはElasticsearchの採用に向けて動き始めたが、「オープンソースソフトウェア（OSS）のElasticsearchは、バージョンアップのスピードがあまりにも速く、それを使った仕組みをサービスごとに構築し、適切に運用していくためには相応の手間とスキルを要することが予想されました。そのため、なかなか導入に踏み切れませんでした」と、加藤氏は振り返る。
そうした問題を解決したのが、ECE (Elastic Cloud Enterprise、以下、略してECE)だった。
「ECEを使うことで、Elasticsearchのバージョンアップを簡単に行うことが可能になりますし、ECEにはElasticsearchを開発しているElastic 社のプロダクトであり、Elasitc 社が運用しているElasitc Cloudで利用されているという安心感もあります。そこでECE の採用に踏み切り、ESaaS の始動に向けて動き始めたのです」（加藤氏）。
実際、ECEでは、Elasticsearchのバージョンアップが「数クリックで完了する」と、KADOKAWA Cloud Service部Server & DataStore課の辻下卓見氏は言う。
「例えば、Elasticsearchのバージョンアップが行われたときに、必要な情報をECEに登録してアップデートのボタンを2～3つクリックして待つだけで、Elasticsearchクラスターのバージョンアップ作業が全て完了します。作業は非常に簡単で、更新作業中もクラスターの動作に影響がありませんので、運用管理の担当者としてとても助かります」（辻下氏）。
Elasticsearchクラスター利用のセルフサービス化を実現
ECEの採用を決めたインフラチームではESaaS (Elastic Stack as Service、以下ESaaS)の構築に着手し、2019年に本番運用を始動させた。そのESaaSでは、ElasticsearchクラスターをKADOKAWAグループ内のエンドユーザーに個別に提供し、自由に使ってもらうという考え方の下、「運用のセルフサービス化」が図られている。
例えば、Elasticsearchなどのインスタンスの作成（とエンドユーザーへの払い出し）をはじめ、スケールアップ、スケールアウトは全てエンドユーザーがセルフサービスで行えるようになっている。また、エンドユーザーが ESaaS上のElasticsearchやKibanaの機能検証を十分に行えるよう、ESaaSの全ての機能を14日間試用できるトライアル機能も提供されているほか、事前の障害試験を通じた復旧の自動化も図られている。
ちなみに、上記のセルフサービス化に当たっては、当初、ECE の管理画面をエンドユーザーに開放することも検討された。ただし、ECEがマルチテナント型のサービスではないことから、そこまでの権限をエンドユーザーに持たせてしまうのには、情報セキュリティ上のリスクが大きくあった。
そこで、辻下氏らは、ECE APIを使ってエンドユーザー用の管理ツールを内製し、“疑似的なマルチテナント環境”を作り上げたという。この内製ツールは、ソフトウェアのビルド、テスト、デプロイの自動化ツール、Jenkins が実行するかたちでエンドユーザーに提供されている。
図：ESaaSのシステム構成イメージ
「ECEのAPIを活用すると、ECEの管理画面で実行できること──すなわち、管理者がやりたいことは全て実装できます。私たちは、そのAPIを使ってエンドユーザー向けの管理ツールを内製し、Elasticsearchクラスター活用のセルフサービス化を実現したわけですが、これにより、Elasticsearchインフラの運用管理にかけるインフラチームの労力はおよそ0.1人月で済んでいます。インフラの運用管理担当者にとって、ECE APIが充実していることのメリットは非常に大きいと言い切れます」（辻下氏）。
プライベートクラウドの利用者満足度を上げインフラ運用管理コストを引き下げる
辻下氏のチームでは、自らもESaaSを使い、SDS（Software Define Storage）の障害調査の効率化を実現している。
以前は、SDSの障害調査を行う際に、10数台のサーバ（ノード）に1台ずつログインして、ログを収集して分析をかける必要があった。それが現在は、サーバの全てのログがECE上のElasticsearchクラスターに自動的にまとめ上げられ、ダッシュボードを見るだけで、「エラーがどのノードで発生したのか」「そのエラーによって、どのSDSユーザーに影響が出ているか」がすぐに確認できるようにしてあるという。また、前出の図からも分かるとおり、ESaaSは、社内のチャットツール、Slackとも連携しており、ログ分析に基づくアラートはSlackを通じて関係者全員に知らされるようにもなっている。
「このように、障害の調査や関係者へのアラート発信のプロセスを効率化・自動化することで、サービスを運用する担当者の負荷が大きく減らせます。また、調査の作業に特殊なスキルが必要ではなくなり、エンジニアの組織内での流動性が高められるわけです」（辻下氏）。
また、辻下氏によれば、同様の障害調査の仕組みは、「DataDog Logs」や「CloudWatch Logs」といったSaaSサービスを用いることでも実現できるが、これらのサービスは、ログの流量に応じた従量課金制を採用しているため、ログの流量に気を配りながら、開発・運用を進める必要があるという。
それに対して、ESaaSではログの流量ではなく、ログの保存可能容量に応じた固定費のみでのサービス利用ができる仕組みになっている。そのため、エンドユーザーにとっては調査のコストが見えやすくなり、調査に想定外のコストを使ってしまうリスクも回避しやすくなるようだ。
こうしたESaaSは、エンドユーザーからの評価も高く、利用者アンケートをとったところ、全員がESaaSの使用によって「業務が楽になった」と回答したという。また、現状ではサービスの問題調査やアラート通知の効率化・自動化にESaaSの用途が集中しているものの、アプリケーションパフォーマンスの調査やログの監視、レコメンド最適化アルゴリズムの分析などにもESaaSを使おうとする動きも見られているという。
さらに、ESaaSを利用する組織も、ドワンゴからKADOKAWAグループ全体へと広がろうとしており、それに伴い、ESaaSを通じてセキュリティログの相関分析を可能にする「Elastic SIEM（Security Information and Event Management）」や、システム横断でのコンテンツ検索を可能にする「Elastic Workplace Search」を使いたいという声も挙がっているという。
「Elastic Stackは機能が豊富で、適用範囲も広いソリューションです。今後は、KADOKAWAグループ内での活用を積極的に推進していきたいですし、それによってインフラ運用のコスト削減と、エンジニアの流動性の向上に大きく貢献できると見ています」（加藤氏）。
