はじめに
はじめまして、KCS 部の島崎です。 KCS部は、KADOKAWAグループ向けプライベートクラウド(以下KCS)を提供しており、主な利用者は株式会社ドワンゴがサービスを提供している『niconico』です。
私は RDB基盤と CACHE基盤と今回の Elastic Stack as a Service (以下 ESaaS) の開発から携わり、現在もそれらの運用を行っています。今回は ESaaS の紹介と ESaaS が利用している ECE 及び内製ツールについて投稿します。
ESaaS (Elastic Stack as a Service) とは
ESaaS とは KCS が提供する Elasticsearch のマネージドサービスです。Elastic社が提供している Elastic Cloud をオンプレミスにホスティングする製品の Elastic Cloud Enterprise (以下 ECE) を利用しています。RDB基盤やCache基盤は VM でしたが、ESaaS ではログ閲覧を主なユースケースに定義しており、Diskスループットが必要なため VM ではなくベアメタルサーバで利用しています。
ESaaS が生まれるきっかけ
障害発生時にログを調査したい場合、どのように調査するのが良いでしょうか?ESaaS がリリースされるまでは、主に3つの選択肢しかありませんでした。
まずひとつめが、各利用者が保守するサーバにログインしてサーバ内にあるログファイルを grep して情報を得るというものです。この方法ですと運用者が手作業で実施するため職人芸になり属人性が高く、かつログを可視化ができないという問題を抱えています。さらにサーバ台数が多いと運用負荷が高まり、問題発生時の調査時間に費やす時間の長さに直結します。
次に、DataDog LogsやCloudWatch LogsといったSaaSサービスを利用する方法です。これら SaaS サービスではログ流量に応じた従量課金のため、ログ出力の際に流量に気を配る必要が出てきます。
最後に、自前でElasticsearchとKibanaなどを運用する方法もありますが、各サービスごとに構築・運用するには、小規模なチームでは学習コストも含めて中々手を出せない現状がありました。
これらを解決するためにESaaS のサービス提供が始まり、Kibana を利用してログの可視化を行うことができ、さらにオンプレミスのため固定費で利用することができるようになりました。
なぜ Elastic Cloud Enterprise を利用するのか?
ECE 使わずともオープンソース版の Elasticsearch と Kibana を使って同様のサービスを提供することはできます。しかし以下のように Elasticsearch はリリースサイクルが早く、パッチバージョンも合わせるとさらに多くなります。Private Cloudとして提供する際に運用負荷を下げることはとても重要なのですが、このバージョンアップに追従するコストが運用負荷を上げるであろうと予想しました。
バージョン | 提供日 |
---|---|
7.6.0 | 2020/2/12 |
7.5.0 | 2019/12/3 |
7.4.0 | 2019/10/1 |
7.3.0 | 2019/7/31 |
7.2.0 | 2019/6/26 |
7.1.0 | 2019/5/20 |
7.0.0 | 2019/4/11 |
ECE では自身の機能によりバージョンアップまたはバージョンダウンを実施することが簡単にでき、Elastic 社自身が開発し、Elastic Cloudでも実際に利用されていることから ECE を採用するに至りました。また、ECE では API が提供されているため、後述の ESaaS のセルフサービス化にも貢献しています。
ESaaS の特徴
少人数の DSRE チームで運用できるように基盤の運用コスト削減が最重要視されます。そのため、基盤の運用作業自体の見直しが行われました。
発生する定常作業 | 運用コスト削減のための対応 |
---|---|
インスタンスの払い出し | 利用者によるセルフサービス化 |
インスタンスのスケールアップ | 利用者によるセルフサービス化 |
インスタンスのスケールアウト | 利用者によるセルフサービス化 |
利用者の問い合わせ対応 | トライアル提供及び健全性の自動チェック機能 |
障害発生時の対応 | 事前の障害試験による復旧自動化 |
これらの対応により ESaaS の基盤運用コストは 0.1 人月未満で行われています。
セルフサービス化
利用者のインスタンスの払い出し、スケールアップ、スケールアウトを定常運用として行われていますが、これらは運用コストに直接かかっていきます。そのため、ESaaS ではこれらをセルフサービスとして提供できるように開発されました。
当初は ECE の管理画面を開放するつもりでしたが、管理画面で何でも出来てしまう問題(権限管理)と後述のトライアル機能の要件を満たすことができなかったため、かわりに ECE API を利用して各種機能を代行で実行する内製ツールを開発し WebUI として Jenkins が内製ツールを実行する形で利用者に提供しています。
トライアル環境の提供、健全性の自動チェック機能&修復方法提案、ナレッジの利用者向け共有
利用者が事前に ESaaS 上の Elasticsearch/Kibana で機能検証を行い、その後 ESaaS を利用できるようにするために14日間全機能を利用できるトライアル機能を提供しています。
また、Beats を使ったログ採取の設定方法や Index Lifecycle Management (以下 ILM) の設定方法などのナレッジを利用者に公開して共有することによりナレッジ上にある問題による問い合わせを減らしています。
さらに、サービス提供後に追加された機能として健全性の自動チェック機能があります。これは毎日定期的に利用者が払い出した全てのクラスタに対して先の内製ツールが診断を行い、発見した利用者自身で解決できるトラブルを解決策とともに利用者の Slack のチャンネルに投稿するものです。これにより自動チェックで発生した問題に対する問い合わせを減らすことができ、運用コスト削減につなげています。
健全性の自動チェック機能が提供するもの
健全性の自動チェックは以下の5項目を診断し、いずれかの条件に一致した場合に Slack のチャンネルに投稿します。
問題の内容 | 解決の提案 |
---|---|
インスタンスのディスク使用量が 90% を超えている | データ削除あるいはスケールアップ後に ILM の設定あるいは見直し |
ディスク使用量が特定のノードに偏っている | インデックスの容量確認 した後に ILM の設定見直し |
ECE からみた健全性状態が緑以外 | データの削除あるいはスケールアップ後にシャードの割り当て API の実行 |
未割り当てシャードが 10 以上発生している | ディスク使用率の確認 |
読み取り専用状態のインデックスが存在する | ディスク使用率を確認した後に index.blocks.read_only_allow_delete を null に設定 |
障害試験
基盤を運用するでは避けることのできない障害試験を6つの項目に分けて実施しました。基盤運用上対応する必要があるものは「2. 恒久的なホストダウン」と「5. 管理コンテナ障害」でそれ以外はハードウェア構成及び ECE の機能によりカバーできます。仮に 2 と 5 のケースの場合でも全台同時に障害が発生しない限りはサービスは稼働し続けることが可能です。
1. 一時的なホストダウン
負荷をかけた状態のまま意図的に電源を落とすことにより再現させます。発生直後は縮退運転状態になるものの、10分未満で復旧状態に移行しました。
2. 恒久的なホストダウン
負荷をかけた状態で1ホストからアプリケーションを削除することにより再現させます。縮退運転になるものの稼働し続けました。
3. ディスク障害
負荷をかけた状態のままディスクの物理抜去により再現させます。RAID10 で構築しているためサービス障害はなく、仮に全てディスク障害が発生した場合は「2. 恒久的なホストダウン」に該当します。
4. ネットワーク障害
Bonding で構成しているためサービス影響はありません。仮に全て障害が発生した場合は「2. 恒久的なホストダウン」に該当します。
5. 管理コンテナ障害
全ての管理コンテナを停止させた場合でも Elasticsearch/Kibana コンテナの影響はありません。ただし、特定の管理コンテナを落とした場合のみ手動起動の必要があります。
6. Elasticsearch/Kibana コンテナの障害
管理コンテナが生きていれば管理コンテナにより再起動されます。
まとめ
ESaaS が誕生するきっかけとしてログ調査にあり、ログ調査の運用コスト削減及び結果の可視化を行うために Elastic Cloud で採用されている ECE を土台に開発が行われました。ESaaS はリリースから半年で10以上のシステムから利用されています。
また、少人数の DSRE チームで安定して運用するために、コスト削減を最優先としています。そのため、運用作業の見直しを行い、1. セルフサービス化 、 2. トライアル機能及び自動チェック機能の提供 、 3. 事前の障害試験実施 を実現した上で ESaaS がリリースされ、ESaaS 運用コストとして現在 0.1 人月で運用されています。
KADOKAWA Connected では、Private Cloud で運用効率化を意識しながら基盤提供する仲間を募集 しています!