ソーシャルネットワークLinkedInのソフトウェアエンジニアらは先頃、同社がLambdaアーキテクチャを廃止した経緯を公開した。
LinkedInの有償機能のひとつであるWho Viewed Your Profile(WVWP)は、以前はLambdaアーキテクチャパターンを使って実装されていた。同社がこのアプローチを選択したのは、バッチ処理のスループットおよび正確性と、ストリーム処理による未完了情報の高速な計算の２つを組み合わせるためだった。ところが完成した実装は、ソリューション全体の運用オーバーヘッドが高く、構造が複雑で、結果としてプロダクトとしてのイテレーション時間が遅くなった。そのためエンジニアらは、Lambdaを使用しないアーキテクチャへのマイグレーションを選択し、それによって開発速度の大幅な改善を実現したのだった。
LinkedInのソフトウェアエンジニアであるXiang Zhang、Jungyu Zhu両氏は、移行の理由を次のように説明している。
システムの進化には、機能拡張やバグ修正、コンプライアンスあるいはセキュリティの変更、データマイグレーションなど、さまざまな理由があります。WYVPではこれらすべての変更が、Lambdaアーキテクチャのために、2倍の労力を必要としていました。さらに悪いことに、Lambdaアーキテクチャではライブラリも開発するのですが、当社は基本的に機能の大半をバッチレイヤとスピードレイヤの両方に実装していたため、2つのレイヤで新たなバグが発生する状況になっていたのです。(...) 最終的に、開発速度を大幅にスローダウンしているという理由から、アーキテクチャを維持する価値がなくなりました。これらの事項を念頭に置いて、WVYPのLambdaアーキテクチャを廃止する作業に着手することになったのです。
下の図は、Lambdaアーキテクチャを使用したWVYPシステムを簡略的に表現したものだ。Lambdaアーキテクチャは、バッチとストリーム処理メソッドとのハイブリッドアプローチを採用したアーキテクチャスタイルである。
出典: https://engineering.linkedin.com/blog/2020/lambda-to-lambda-less-architecture
準リアルタイム("nearline")プロセッサは、入力されたProfileViewイベントを処理する。そのプロセッサの処理結果を、KafkaのトピックがOLAP(online analytical processing)データベースと通知インフラストラクチャ(notifications infrastructure)にフィードする。このプロセッサと並行して、Kafkaのトピックが、ProfileViewイベントと追加的なNotificationイベントの両方をHDFSストア内のデータに追加する。このジョブの結果もOLAPデータベースに(別のテーブルだが)に格納される。そして最後に、APIから結果を取得できるように、プレゼンテーションサービスがマージを行うのだ。
準リアルタイムのプロファイルビュー通知の維持は要件であったため、エンジニアたちは、"旧アーキテクチャにあるオフラインバッチジョブをすべて取り払って、新たなニアライン(nearline)メッセージプロセッサをSamzaを使って開発することにより、アーキテクチャを簡略化する"ことに決定した。次の図はその新たなアーキテクチャを表したものだ。
出典: https://engineering.linkedin.com/blog/2020/lambda-to-lambda-less-architecture
Apache Samzaは、元々はLinedInのエンジニアたちが開発したもので、同社では分散ストリーム処理サービスのデファクトとなっている。Zhang、Zhu両氏は、この選択を次のように説明する。
Samzaはさまざまなプログラミングモデルをサポートしています。そのひとつがBeamプログラミングモデルです。SamzaはBeam APIを実装しているので、フィルタリングやトランスフォーメーション、ジョインといったデータ処理ユニットを簡単に開発することができます。当社の例で言えば、PageViewEventとNavigationEventをジョインして、ビューのソースを準リアルタイムに算出することが簡単にできます — これは旧プロセッサでは簡単ではなかったことです。第2に、ここLinkedInでは、SamzaジョブはSamzaチームの管理するYARNクラスタ上で実行されるので、一度セットアップさえしてしまえばジョブのデプロイやメンテナンスは簡単なのです。(...) そして最後に、Samzaには充実したサポートがあり、LinkedInの他のツーリングや環境との統合も良好である点があります。
エンジニアらによれば、OLAPデータベースに関わる制限のため、Lambdaを廃止した新アーキテクチャでもオフラインジョブの併用は残っているという。ただし、新たな状況では、ストリーム処理とオフラインジョブにビジネスロジックの重複は存在しない。オフラインジョブはあくまでも、データベース内のデータ再編成を最適化する手段という位置付けなのだ。
新しいアーキテクチャでは、ストリームメッセージ処理が冪等でないという理由から、メッセージの再処理可能性(re-processability)という新たな問題が発生する。LinkedInのエンジニアらは、この問題に対する万能策が存在しないことを理解しており、いくつかの異なるアプローチをを組み合わせることで、想定される問題を軽減化するという方針を決定している。実施可能なアプローチには、重要でないエラーにはワンタイム・オフラインジョブによる修正を行い、重要な処理上の問題に対しては(プロセスが非冪等であることは承知の上で)Kafkaのリワインド機能を使用する、というものもある。そして最後に、データ演算が部分的に利用可能な場合の情報消失を処理できるように、プレゼンテーションレイヤの調整を行っている。