ログの実装から活用における負担を減らすための
　型安全なログ・イベントストリーミング基盤

当社では、利用者がWebサイトなどを訪れたり、アプリを操作した際のログをサービスの改善に活用しています。しかし、ログを活用していく中でいくつかの課題が発生していました。C4は、ログのスキーマを適切に管理し、ログが出力されて利用されるまでのシステム全体を通してログを型安全に扱うことで、ログに関わる開発者の負担を減らすことを目指しているログ・イベントストリーミング基盤です。

Member

Software Engineer : 開発・運用担当

使用している主な技術

Protocol Buffers, Apache Iceberg, Bazel, Common Expression Language (CEL), gRPC, Apache Flink, Apache Kafka, Apache Spark, Redis, MySQL, Envoy, Kubernetes, Prometheus, React, Java, Go, TypeScript

システムの概要

解決したい課題/ ユースケース

ログを扱う既存システムを運用する中で、複数の課題が出てきていました。例）

• ログ出力のためのコードを言語毎に手で書いている（バグが起きやすい・開発工数がかかる）
• テーブル上でMap<String, String>型のカラムでログが扱われている（クエリ実行が遅い・圧縮効率が悪い・自動補完や静的検査が効かない・キャストが必要）
• 全サービス共通のJSON Schema（サービス別のスキーマがわからない・oneOfにより実際の型が不明瞭）とサービス別のスプレッドシート（機械可読ではない・不正確）によるスキーマの多重管理

スキーマの活用が難しいことが原因のひとつであったため、C4では、まずはデータ基盤全体で利用するためのスキーマレジストリを開発しました。また、これを活用した仕組みとして、ログのIcebergテーブルへの書き込み機能を開発しました。登録されたスキーマに連動してテーブルの作成、必要なカラムの追加・削除・リネーム・型変更が自動的に行われます。また、データは1分程度の遅延で書き込まれ、Apache Icebergに対応しているBigQueryなどのクエリエンジンから参照できます。

既存システムからの移行と今後の展望

解決したい課題/ ユースケース

スキーマレジストリの導入により、コード生成・テーブルの自動管理などが行えるようになり、間違ったフィールド名、型などでログが出力されることを防ぐことができ、実装・不具合対応に割かれていた工数の削減が見込めます。しかし、そのためには、既存のシステムからの切り替えが必要です。

既存のログ出力箇所をすべて置き換えることは現実的ではないため、まずは、①既存のログをそのままC4に流すコンポーネントを用意、②必要なすべてのログについてスキーマを再定義することで、C4への接続を行いました。これにより、ログ出力側の変更なしに、スキーマが自動管理されたIcebergテーブルを利用可能になりました。

現在は、データ基盤刷新プロジェクトとして、従来のHadoopベースのデータ基盤からマネージドなクラウドデータ基盤への移行と合わせて、これらのテーブルへの利用切り替えが進んでいます。今後は、旧システムをなるべく通らないようにログの転送経路を変更し、旧システムの縮退を進めていくことになります。

これらはまだスキーマレジストリの導入によって実現できることの一部でしかありません。他にも、

• ストリーム上でのカラムレベルのアクセス制御
• ログのバイナリ化（Protocol Buffers）による通信量の削減
• 型安全なストリーム処理

など、いままでは難しかったことも実現しやすくなってきているため、社内でのデータの利活用が便利に安全に行えるよう、今後も継続的な改善に取り組んでいきたいと思います。

関連リンク

ー