2021年11月10日・11日の2日間にわたり、LINEのオンライン技術カンファレンス「LINE DEVELOPER DAY 2021」が開催されました。特別連載企画「DEVDAY21 +Interview」では、登壇者たちに発表内容をさらに深堀り、発表では触れられなかった関連の内容や裏話などについてインタビューします。今回の対象セッションは「マルチテナントなk8sクラスタで構築する信頼性の高いログ収集基盤」です。

LINEはプライベートクラウドのVerda上で、さまざまなマネージドサービスを提供しています。Verdaはマイクロサービスアーキテクチャになっており、各サービスのコンポーネントはマルチテナントなKubernetesクラスタ上にデプロイされています。かつてログ収集の実施は各サービスの担当チームに委ねられていたため、信頼性や可用性、データ永続性、キャパシティ管理に難があり、構築・運用の負担が大きくなっていました。

この状況を改善するため、Verda Reliability Engineeringチームは大量のログを取り扱えるマネージドFluentdを構築し、KubernetesのOperatorの仕組みを用いて、マルチテナント環境におけるログ収集の仕組みを標準化したのです。この取り組みをSite Reliability Engineerの坂本大将が解説します。

いくつもの課題があったログ収集基盤の旧アーキテクチャ

――Verda Reliability Engineeringチームの役割や坂本さんの業務内容を教えてください。

Verda Reliability Engineeringチームは、Infra ManagementとPlatform wide SREという2つのユニットに分かれています。Infra Managementは、Verdaの物理的なインフラリソースの調達や管理・構築をするユニットです。Platform wide SREは、Verda内部で使われるモニタリング基盤などのプラットフォームを開発・運用するユニットです。私は後者のユニットに所属しており、PrometheusやAlertmanager、Grafana Lokiなどのプラットフォームを担当しています。

――「マルチテナントなk8sクラスタで構築する信頼性の高いログ収集基盤」のセッション内で、Verda内でかつて用いられていたログ集計の仕組みに課題があったことを坂本さんは解説されていました。そのアーキテクチャの仕組みと、導入理由や課題について教えてください。

ログ基盤の旧アーキテクチャでは、Verda内にある各サービスのKubernetesのPodの中にサイドカーとしてFluentdとLogrotatedをデプロイし、Emptydirによってコンテナ間でのログファイルの共有をしていました。

このアーキテクチャを用いた利点を敢えて言うならば、サービス開発者たちがロギングの設定を自由に定義できる点と、Dockerのログドライバによる制約を受けない点でしょうか。例えばDockerのログドライバを経由してログを取得する場合、16キロバイト以上のログは分割されてしまう構造になっています。Emptydirから直接的にログを読み取ることで、そうした制約を回避できます。

ただし、この事例においてはなんらかの利点を享受するために旧アーキテクチャを選択したという感じではありませんでした。当時はPlatform wide SREユニットにマネージドFluentdを専任するエンジニアがおらず、やむを得ず各々のサービス開発者が自分たちでログの設定を行うアーキテクチャが導入されたのではないかと思います。

旧アーキテクチャは3つの課題を抱えていました。まずは、ひとつのPodあたりのコンテナの数が増えすぎてしまうこと。次に、すべてのサービス開発者が自分たちでFluentdをメンテナンスしなければならないこと。そして、モニタリングやキャパシティ管理、パフォーマンス管理や信頼性やデータ永続性などの配慮がチームごとにまちまちであることです。こうした問題を解消するため、ログ集計方法を抜本的に見直すことにしました。

より良いログ基盤を実現するための設計上の工夫

――そのためにアーキテクチャの刷新をしたわけですね。

そうです。解決策として、マネージドなFluentdクラスタと、Fluentdの設定ファイルを自動的にバリデーションするFluentd Config Operatorを提供することに決めました。

――新アーキテクチャで、マネージドなFluentdクラスタを構想・設計する際に工夫したことがあれば教えてください。

いくつか考慮した点がありました。標準出力からログを取得する場合には、Kubernetesの全クラスタのNodeにFluentdを配置する必要があります。これらのFluentdでバッファリングや複雑なフィルタリング、加工処理などを実施すると、NodeのCPU・メモリリソースを大量に消費してしまうため、Kubernetesクラスタの動作に悪影響があります。

そのため新アーキテクチャでは、FluentdをForwarderとAggregatorに分け、Kubernetesの各NodeにはForwarderを配置する構成にしました。Forwarderではログの転送のみを行い、Aggregator側でログに対する複雑な処理を行います。また、Aggregatorで何かトラブルがあった場合にすぐ検知できるように、多数の監視を行っています。

また、各サービス開発チームの設定が競合しないように、Fluentdのラベルという機能を用いて、それぞれのPodの設定を疎結合にしました。他にも、各々のチームが好き勝手に独自のラベルを作らないように、機能上の制約を加えています。こうした工夫により、特定チームの作業が別チームに波及しないようにしました。アーキテクチャのさらなる詳細についてはセッションで解説していますので、よろしければ動画をご覧ください

――セッションでは今後の予定として、Kafkaを使ったアーキテクチャ改善を検討されている旨を語られていましたね。

Kafka導入後のアーキテクチャでは、ForwarderはKafkaに対してログを転送し、AggregatorはKafkaからログを取得する構成になります。LINE社内には非常に高いサービスレベルで運用されているマネージドなKafkaがあるため、これを活用することを考えています。

――マネージドFluentdクラスタの構築時点でKafkaを組み込む案もあったと思うのですが、初期段階で見送った理由などがあれば教えてください。

確かにKafkaを導入する案も当初に検討しました。ですが初期構築しているフェーズでは、新アーキテクチャでの運用がうまくいくか不透明だったため、まずはシステムの構成をシンプルにして、早い段階でリリースすることを優先しました。問題なく運用できたため、拡張的にKafkaの導入を決めたという流れです。

利便性の高いFluentd Config Operatorを実現するために

――次はFluentdの設定ファイルを自動的にバリデーションするFluentd Config Operatorのエピソードを聞かせてください。これはどのような仕組みなのでしょうか？

Fluentd Config Operatorは、カスタムリソースで記述された設定を自動的にバリデーションするための仕組みです。設定のバリデーションが失敗した場合は、そこで処理をブロックします。成功した場合は自動的にFluentdの設定に変換し、ConfigMapとして出力します。もしもConfigMapに設定更新があったときは、Fluentdにその情報を伝えます。

――Fluentd Config Operatorを利用者や運用者にとって使い勝手の良い機能にするために、設計で工夫された点はあるでしょうか？

大きく分けて3つあります。1つ目は過度な抽象化を行わないこと。サービス開発者たちは、ロギングの設定をCRD（Custom Resource Definitions）に記述するのですが、使用できるパラメータはFluentdの設定ファイルに関する公式ドキュメントを読めばわかるようになっています。もし必要以上の抽象化をしてしまうと、サービス開発者がCRDを記述するための文法をわざわざ覚える必要が生じ、学習コストが高くなってしまいます。

2つ目はフィルタリングや加工処理の内容やログの取得元、保存先などの情報を、CRDを読めばわかるようにすること。3つ目が、先ほども述べたように特定チームの設定が別チームに波及しないように疎結合にすることです。こちらも、より詳細な情報についてはセッションで解説していますので、ぜひ動画をご覧ください。

――新アーキテクチャの構築後、処理性能に問題がないかを確認するために本番環境へのダークローンチを行い、負荷試験を実施したことを坂本さんは解説されていました。企業やチームによっては、負荷試験用の環境を構築してテストをするケースもありますよね。その手法と比べてダークローンチはどのような点が優れていますか？

ダークローンチの一番の利点は、本番環境と完全に同等のデータで検証できる点です。特定の内容・サイズのログで再現する不具合などを発見できます。Verdaの場合、マネージドサービスの種類が多岐にわたるため、どのようなログが出力されるのかを事前にすべて調べてリスト化することは難しいと思いました。

そのため、負荷試験環境やQA環境での検証よりも、本番環境におけるダークローンチによる検証のほうが利点が大きいと考えたのです。実際に、ある特殊なログの場合だけデータの保存に失敗するケースを、このテストで見つけることができました。

――非常に学びの多いインタビューでした。最後に、KubernetesクラスタやFluentdの運用に携わる読者の方々に、ご自身の経験をふまえて伝えたいことはありますか？

LINEのように自社でKubernetesクラスタを管理・運用している組織の場合、クラスタの共有リソースを取り扱うためのOperatorを作成し、複数チームの設定情報が競合しないようにするというアプローチは、他のツールやプラットフォームにも応用可能だと思います。実際、私たちは今後PrometheusやAlertmanagerなどの設定も、同じようにOperatorで運用していきたいと構想しています。ぜひ参考にしていただけたら嬉しいです。

採用情報

LINE株式会社では一緒に働くエンジニアを募集しています！今回のインタビューと関連する募集ポジションはこちらです。

・Site Reliability Engineer（SRE） / Infra resource management / Private Cloud Platform
・Site Reliability Engineer（SRE） / Platform-wide solution / Private Cloud Platform
・Software Engineer / Cloud Native Platform / Private Cloud Platform
・Software Engineer / IaaS platform / Private Cloud Platform
・Senior Software Engineer / IaaS platform / Private Cloud Platform