AirbnbのHomes、Experiences、Servicesへの事業拡大は、オフラインデータウェアハウスのためのデータモデリングフレームワークの刷新を必要とした。中核的な課題は、データサイロと技術的負債を回避するために、一貫性と柔軟性のバランスを取ることだった。彼らは、中央集権的な原則と分散型のモデリングガイドラインを組み合わせたバランスの取れたアプローチを選択した。3つの基本的な原則が一貫性を保証した。それは、ハイブリッドモデルの排除、一貫した識別子命名規則、明確な名前空間の整理である。モデリングガイドラインは、共有属性と固有属性、将来の進化、下流のコンシューマーに基づいて、個別のモデルかモノリシックなモデルかの選択をチームに委ねた。Listings、Availability、Location、Guest interactionsのようなプロダクト固有のドメインは、属性が異なるため個別のモデルを選択した。逆に、Messaging、Payments、Customer Supportのような横断的な概念は、統一されたビューのためにモノリシックなモデルの恩恵を受けた。オフラインデータウェアハウスは、分析のために生のプロダクションデータを標準化する重要な翻訳レイヤーとして機能する。レガシーテーブルの移行を含むデータ負債の管理は、慎重なコミュニケーションと検証を必要とする重要な取り組みだった。このフレームワークは、Airbnbの進化するデータニーズに対して、スケーラブルで一貫性のある基盤を提供した。

Airbnbは、数千のサービスインスタンスに動的な構成変更を確実に配信するために、軽量なKubernetesサイドカーであるsitarエージェントを開発しました。構成配信は、開発者がGitまたはUIを通じて値を生成または更新することから始まり、それらはSitar Serviceに保存されます。定期的に、構成の完全な状態は圧縮されたスナップショットにパッケージ化され、AWS S3にアップロードされます。サービスポッドが起動すると、sitarエージェントはまずこれらのS3スナップショットをマウントされたディスクにダウンロードし、迅速なブートストラップを可能にします。その後、スナップショットが作成されてからの変更についてSitar Serviceと同期し、メインアプリケーションコンテナに準備完了を通知します。起動後、エージェントは数秒ごとにSitar Serviceを継続的にポーリングして更新を取得します。メインアプリケーションコンテナは、値のキャッシュとファイル変更の検出を行うSitarクライアントライブラリを使用して、マウントされたディスクから構成を読み取ります。重要な設計上の決定は、わずかなコスト削減よりも信頼性、運用上の安全性、および多言語サポートを優先して、sitarエージェントをメインコンテナに統合するのではなく、個別のサイドカーコンテナとして維持することでした。このシステムは、サーバーサイドキャッシュとトークンベースのデータベースアクセスで最適化されたエージェントがSitar Serviceをポーリングするプルモデルを使用しており、負荷を軽減します。ローカルのオンディスクキーバリューストアには、AirbnbはSQLiteの優れた同時実行性、パフォーマンス、および多言語サポートにより、レガシーのSparkeyベースの実装よりもSQLiteを選択しました。SQLiteの組み込みのWrite-Ahead Loggingは書き込み中の同時読み取りを可能にし、そのシンプルな運用モデルは、RocksDBの高いパフォーマンスとより大きな複雑さよりも好まれました。この堅牢なサイドカー設計により、Airbnbの広大なサービスフリート全体で重要な構成が迅速かつ確実に配信されることが保証されます。

COVID-19パンデミックは、歴史的なパターンを混乱させ、従来のモデルを信頼できないものにしたため、予測上の課題を提示しました。需要の回復は非同期かつ地理的に不均一であり、ワクチンの展開や国境の再開には様々なタイムラインがありました。回復中の各市場でローカルデータを待つことは、長期間にわたって盲目的に予測することを意味したでしょう。Airbnbの解決策は、時間的に過去を見るだけでなく、地理的に横を見ることにありました。 彼らは、回復が順次展開し、ある回廊が他の回廊よりも先に変化を経験することに気づきました。重要なシグナルは、予約リードタイムの平均であり、これは混乱中に圧縮され、回復中に長くなりました。ヨーロッパや北米のような地域間でこれらのリードタイムシフトのタイミングを比較することにより、ある市場が別の市場の経験に基づいて再開にどのように対応するかを推測することができました。これにより、早期に影響を受けた回廊の後部を、後に影響を受けた回廊の情報提供的な先行として使用することができました。 この先行伝播メカニズムは、ローカルデータが乏しい市場でも、リアルタイムの学習と予測を可能にしました。このアプローチには、詳細なデータを持つグローバルなフットプリントと階層ベイズモデリングフレームワークが必要でした。この方法論は、新しい製品機能の展開や規制変更の影響を予測する場合など、危機を超えて適用可能です。これにより、早期採用市場からの即時の学習を、まだ変化を経験していない市場の予測に反映させることができます。

Airbnbは、パフォーマンス向上のためにPaaSグラフデータベースの使用から、社内ナレッジグラフインフラストラクチャの構築へと移行しました。信頼と安全に不可欠なアイデンティティグラフは、当初リレーショナルデータベースに依存し、その後SaaSグラフに移行しましたが、スケーラビリティとレイテンシの課題に直面しました。JanusGraphとDynamoDB上に構築された、社内で管理される新しいインフラストラクチャは、統一されたプラットフォームを提供します。カスタムトランザクションや並列クエリ実行などの主要な最適化が、Airbnbのパフォーマンスニーズを満たすために実装されました。このプラットフォームは、スキーマ強制によるマルチテナント運用をサポートします。Gremlinクエリの書き換えを含むクライアントサイドのクエリ最適化により、さらにパフォーマンスが向上しました。社内グラフインフラストラクチャは、スケーラビリティを大幅に向上させ、システム安定性を改善しました。様々なクエリパターンでパフォーマンス向上が達成され、APIの読み取り応答時間が短縮されました。自己管理システムにより、インシデントの解決が迅速化されました。新しいシステムは、以前のソリューションの10倍の書き込みQPSにスケールしました。この移行により、複雑なクエリのP99レイテンシが大幅に削減されました。Airbnbのナレッジグラフは、現在、重要なユースケースをサポートしています。

ViaductはAirbnbのデータ指向サービスメッシュであり、安定したAPIを持つコミュニティ主導のプロジェクトとしてリリースされました。様々なデータソースへのアクセスと対話のためのGraphQLベースのインターフェースとして機能します。Viaductの目標は、組織のデータに対する中央スキーマを提供すると同時に、分散開発を可能にすることです。GraphQL Federationとは異なり、Viaductは共有マルチテナントランタイムでホストされるモジュールを通じて開発を分散させます。チームはSDLとリゾルバを持つモジュールを作成することで貢献し、ドメインロジックに焦点を当てます。Viaductは、フェデレーションアーキテクチャ内のサブグラフとしても機能できます。1.0リリースには、注釈による新機能、安定性、および自動リリースが含まれています。Airbnbは、GitHubを使用してアーキテクチャに関する議論を行い、コミュニティへの関与にコミットしています。この記事では、AirbnbエンジニアによるGraphQLConf 2026での今後の議論を強調し、Viaductの機能を紹介しています。これらには、確率的テスト、監視、シャーディングソリューション、およびLLMを使用したモックデータの生成が含まれます。この発表は、データレイヤーを統合したい、またはプロジェクトに貢献したい人々からの関与を奨励しています。

中核的な問題は、監視対象のインフラストラクチャが障害を起こした際に、オブザーバビリティシステムも障害を起こす可能性があり、循環的な依存関係が生じることです。Airbnbは多くの組織と同様に、メトリクスパイプラインが監視対象と同じシステムに依存するというこの問題に直面しました。信頼性の高い監視、特に障害発生時の監視を確保するためには、この依存関係の連鎖を断ち切る必要がありました。これを解決するために、Airbnbはクラウドチームが管理する専用のKubernetesクラスタを使用してコンピューティングを分離しました。彼らはネットワーキングを再考し、テレメトリのためにサービスメッシュをバイパスするカスタムEnvoyベースのレイヤー7イングレスレイヤーを構築し、優先順位付けと分離を確保しました。メトリクスはユニークに大量であるため、専用のネットワークパスは輻輳や潜在的な障害を回避します。Airbnbはまた、オブザーバビリティスタック自体を監視して潜在的な問題を検出するメタ監視を実装しました。メタ監視の重要な部分は、監視システムの障害を検出するための「デッドマンズスイッチ」メカニズムの使用です。この全体的なアプローチは、オブザーバビリティ設定におけるサイレント障害から保護する堅牢なシグナルチェーンを作成します。重要なのは、監視を本番システムとして扱い、その信頼性が監視対象システムの信頼性を超えるようにすることです。これは、迅速なインシデント対応を可能にし、ユーザーとビジネスの信頼を維持するために不可欠です。これらの原則は普遍的に適用され、堅牢なシステム設計のために障害ドメインを分離することを含みます。

Airbnbは、保険請求のような複雑なワークフローの永続的な実行という課題に直面していました。外部オーケストレーションエンジンなどの既存のソリューションには、運用上の複雑さやベンダーロックインなどの欠点がありました。これらの問題を解決するために、Airbnbは各サービス内で実行される組み込みワークフローエンジンであるSkipperを開発しました。Skipperは、簡潔さ、単一障害点の排除、既存のデータベースの使用を優先しています。Skipperの設計の中核には、個々の操作をカプセル化するロジックとアクションを定義するワークフローが含まれています。永続性は、アクションの結果をデータベースにチェックポイントするリプレイメカニズムによって実現されます。リプレイにより、ワークフローは中断後、中断した場所から再開できます。状態フィールドは、効率のために永続化され、シグナルを使用してワークフローの状態を更新します。Skipperを使用したワークフローのテストは、キューを設定したり、インフラストラクチャをモックしたりする必要がないため、簡素化されています。このアプローチにより、依存関係を追加したり、パフォーマンスを損なうことなく、永続的な実行が保証されます。

Airbnbは、1秒あたり5,000万サンプル、2.5ペタバイトの時系列データを処理するために、社内ストレージシステムを開発しました。この移行は、進化する製品とインフラストラクチャ全体にわたる広範なコード計測によって生成される膨大な量のデータが原因で必要となりました。主なエンジニアリング上の課題は、この大規模なデータセットを高性能に永続化し、提供することでした。 この規模を管理するために、Airbnbはマルチテナントアーキテクチャを採用し、安定したグループ化と属性付与のために、テナントをサービスまたはプロセスごとに分離しました。シャッフルシャーディングを実装してテナントのワークロードを分離し、テナントがノードのサブセットに対してのみ書き込みとクエリを行うようにすることで、フォールトトレランスを向上させました。運用上の複雑さ、特にテナントのオンボーディングと構成管理は、オンボーディングを自動化し、構成の更新を簡素化する統合されたコントロールプレーンによって対処されました。 システムの主要な要件には、1秒あたり5,000万を超えるサンプルを処理すること、多数のダッシュボードとアラートをサポートすること、および低いクエリ実行時間を維持することが含まれていました。シャドウクラスターを使用した初期検証では、信頼性の問題、コンパクションの遅延、特に大きなデータペイロードでの遅いクエリパフォーマンスが明らかになりました。これらの課題への対処は、単一のクラスターの信頼性を確保することから始まり、ベンチマーク、ガードレール、およびクエリパスの分離を通じて、書き込み、読み取り、およびコンパクションの安定化に焦点を当てました。 システムは、3つのゾーンにデプロイされたゾーン対応のステートフルコンポーネントを使用して、フォールトトレラントになりました。効果的なフリート管理とシステム保護のために、レプリカごとの制限とテナントレベルの制御が実装されました。その後、障害の範囲を縮小し、柔軟性を高めるために、マルチクラスターアーキテクチャが採用されました。 ただし、このマルチクラスターアプローチは、メトリクスの検出、クエリ、および運用上のオーバーヘッドに複雑さをもたらしました。これらは、テナントとクラスターのマッピングのためのツールと、Kubernetesオペレーターを使用した自動化されたデプロイ戦略によって軽減されました。カスタム拡張機能を備えたPromxyの導入により、クロスクラスターのクエリとアラートが容易になりました。 この道のりからの重要な教訓には、クロスクラスタークエリの大きなコストと、自動化と標準化されたデプロイメントを通じて実現されるデプロイメントの一貫性の重要性が含まれます。哲学は、クラスターを重要な、ユニークな「ペット」ではなく、使い捨てのリソースである「家畜」として扱うように進化し、スケーリングとメンテナンスが容易になりました。最終的に、このプラットフォームの構築には、アーキテクチャの革新、運用上の厳格さ、および期待値を管理する文化的な変化の組み合わせが必要でした。

Airbnbは、エクスペリエンスを通じたコミュニティのつながりを重視し、よりソーシャルなプラットフォームへと進化しています。プラットフォームは、内部ユーザーデータと公開プロフィールを区別することで、ユーザーのプライバシーを優先しています。ユーザーは、エクスペリエンスで共有する情報を選択し、プロフィール表示を管理できます。これを実現するために、Airbnbは、柔軟なプライバシー設定を可能にするために、異なるコンテキストでユニークなユーザーIDとプロフィールIDを使用しています。これにより、ユーザーはホストとゲストなど、必要に応じて分離された複数のプロフィールを持つことができます。Airbnbは、Himejiと呼ばれる権限システムを採用し、最小権限のアクセスと強力なデータセキュリティを確保しています。この実装には、適切な識別子の使用を確実にするための自動監査、チームコラボレーション、AI支援のリファクタリングが含まれていました。移行中のデータ整合性を維持するために、型安全性と厳格なテストが不可欠でした。最終的に、Airbnbのプライバシー原則は、ソーシャル機能と個人情報に対するユーザーの管理とのバランスを取ることを目指しています。このアプローチは、Airbnbコミュニティ内でのつながりとプライバシーの両方を育むように設計されています。このシステムは、ユーザーが自信を持って他の人とつながり、共有できるようにするために導入されています。

この移行は、大規模なメトリクスパイプラインをStatsDからOpenTelemetryとPrometheusに移行し、メトリクスの収集を前倒しにすることを目的としていました。当初は、内部サービスにはOpenTelemetry Protocol (OTLP) を使用して計装し、OSSワークロードにはPrometheusを使用し、StatsDをフォールバックとしていました。共有メトリクスライブラリを活用したデュアルライトアプローチにより、OTLPへの移行が容易になりました。その結果、パフォーマンスが向上し、ヒストグラムなどのPrometheusの機能を利用できるようになりました。しかし、高カーディナリティのメトリクスがパフォーマンスの低下を引き起こし、一部のサービスでデルタテンポラリティを使用することで対応しました。コスト削減と変換を可能にするために、vmagentを使用したPrometheusベースの集計パイプラインが実装されました。Prometheusの`rate()`関数が、リセットイベントにより特定のカウンターを過小評価するという問題が発生しました。この不一致を修正するために、集計中にゼロインジェクションを実装し、ユーザーには透過的に行われました。これにより、カウンターの問題が解決され、データの正確な表現が保証されました。最終的に、チームはこれらの変更を実装することにより、将来を見据えたメトリクスインフラストラクチャを実現しました。

元プロフットボール選手だったジョナサン・ウッドワードは、プログラミングへの情熱を燃やし、キャリアをソフトウェアエンジニアリングへと転換しました。彼はAirbnbのConnect Engineering Apprenticeshipプログラムに参加し、学び成長できる新しい環境を見つけました。この見習いプログラムは、構造化された学習、チームコラボレーション、そしてメンターシップを提供し、彼の転換にとって不可欠なものでした。プログラム期間中、彼は当初は考えていなかったバックエンドエンジニアリングを探求しました。彼はそこで優秀な成績を収め、最終的にはAirbnbのセキュア開発エンジニアリングチームで正社員のポジションを獲得しました。彼の仕事は、IDとアクセス管理、脆弱性管理に焦点を当てており、LLM（大規模言語モデル）の統合という新たな課題にも直面しています。ウッドワードは、フットボールとセキュリティエンジニアリングの間には、特にプレッシャーのかかる状況やチームワークにおいて類似点を見出しています。彼は、自身の成功はチームとAirbnbの協調的な文化のおかげだと語っています。彼は、従来のテックキャリアとは異なる道を進む人々を励ますために、自身の経験を共有しています。現在、彼は卒業生ホストとして、新しい見習いをサポートしています。彼はこの仕事にやりがいを感じており、自身の経験を活かして迅速な意思決定を行っています。

Airbnbの財務計画に不可欠な予測モデルは、COVID-19パンデミック中に深刻な混乱に見舞われました。主な課題は、これまで安定していた予約と旅行日の関係が非常に不安定になったことです。この問題に対処するため、Airbnbは予測を2つの要素に分けました。それは、総予約額とリードタイム構成です。彼らは、予約リードタイムに関連する変化する割合を処理するために特別に設計されたB-DARMAモデルを開発しました。驚くべきことに、総予約額が回復した後でさえ、リードタイム構成は持続的な変化を示し、パンデミック前のパターンには戻りませんでした。Airbnbは、これらの長期的な変化を監視し、定量化するために、分布発散メトリックを使用しました。これは、モデルの健全性を診断するための重要なツールとなりました。これらの永続的な変化は、収益予測、キャッシュフロー、および運用上の意思決定に直接影響を与え、正確な分布モデリングの重要性を浮き彫りにしました。予測を改善するために、彼らは構造的ブレークから学習する能力を開発し、モデルが変化に適応できるようにしました。これらの要素を分離して分析することにより、Airbnbは、構造的変化を検出し、適応できる、より回復力のある予測モデルを作成しました。

Airbnbは、オブザーバビリティプラットフォームを、ベンダー管理サービスから、オープンソース技術に基づいた自社ソリューションに移行しました。主な動機は、コスト削減と、データとワークフローに対するより大きな制御を得ることでした。最初の移行戦略では、複雑なサービスから着手しましたが、これは非効率であることが判明しました。改訂された戦略では、実現可能性を証明し、強固な基盤を確立するために、よりシンプルなサービスの移行に焦点を当てました。新しいアプローチでは、ユーザーにあまりにも多くの変更で圧倒されないように、即時のクエリ改善よりも完全な移行を優先しました。既存のダッシュボードとアラートを新しいシステムにマッピングするための翻訳ツールを構築しました。直接的な翻訳ではなく、クエリの意図の移行に焦点を当て、誤ったパターンを修正しました。メタデータエンジンの実装により、新しいシステムでの正確なメトリックタイピングが保証されました。広く理解されているクエリ言語であるPromQLを採用し、クエリ生成を支援するAI搭載ツールを統合しました。また、移行により、時代遅れのアラートフレームワークの置き換えも可能になりました。この包括的な見直しにより、優れたツール、一貫したデータ、そして大幅に改善された開発者エクスペリエンスが実現しました。

Airbnbのチームは、旅行計画の初期段階でユーザーを支援するために、目的地推薦モデルを開発しました。このモデルは、まだ目的地や旅行日を決めていないユーザーの課題に対応します。モデルは、Airbnbプラットフォーム上での検索や予約といったユーザーの行動を分析することで、ユーザーの目的地への意図を予測します。主な革新点は、多様なシグナルを統合し、アクティブなユーザーと休眠中のユーザーの行動のバランスを取り、ロケーション知識を組み込んでいることです。モデルはトランスフォーマーアーキテクチャを使用し、ユーザーの行動をトークンとして扱い、ユーザーの好みを理解します。トレーニングデータは、予約に近いアクティブなユーザーと、初期計画段階の休眠中のユーザーの両方に対応できるように特別に設計されています。マルチタスク学習を使用して、地域レベルと都市レベルの両方の目的地を予測し、ロケーションの理解を向上させています。このモデルは、オートサジェストと放棄された検索のメール通知を強化し、ユーザーが潜在的な目的地を発見するのを支援します。オートサジェストでは、都市の推薦を提供し、特に非英語圏での予約増加につながっています。放棄された検索のメールでは、推奨エリアのリスティングを掲載し、予約完了を促進します。探索段階に焦点を当てることで、モデルはインスピレーションを刺激し、意思決定の摩擦を減らし、ユーザーエンゲージメントを高めることを目指しています。このフレームワークは、旅行時期や価格の好みを含む、旅行計画体験全体のパーソナライゼーションの基盤を提供します。

AirbnbのキーバリューストアであるMusselは、当初、単一のクライアントがシステムを圧倒するのを防ぐために、シンプルなQPSレート制限を使用していました。トラフィックが増加し、複雑になるにつれて、このアプローチはコストの変動とトラフィックの偏りのために不十分であることが判明しました。これに対処するため、Musselは多層的なサービス品質（QoS）システムを実装するように進化しました。最初の層であるリソースアウェアレート制御（RARC）は、リクエストをリクエストユニット（RU）で課金し、行数、バイト数、レイテンシを考慮して、実際のバックエンドコストを反映します。このシステムは、各呼び出し元に対して静的なRUクォータを持つトークンバケットを使用します。 2番目の層であるロードシェディングは、容量が逼迫したり、ホットスポットが発生した場合にリアルタイムの保護を提供します。トラフィックの重要度、システムのストレスを示すレイテンシ比率、およびCoDelにインスパイアされたキューイングポリシーを組み合わせます。これにより、高優先度のトラフィックは応答性を維持し、レイテンシが上昇した場合は他のトラフィックを段階的にバックオフさせることができます。3番目の層であるホットキー検出とDDoS防御は、特定のデータをターゲットとする同一のリクエストの急増を特定し、軽減します。リアルタイム検出にはインメモリのtop-kカウンター、ディスパッチャーポッドでのローカルキャッシング、重複するホットキー検索のためにストレージ層に1つのリクエストのみを送信するためのリクエスト合体を使用します。 これらの多層的な制御により、Musselはトラフィックの急増を処理し、信頼性を維持する能力が大幅に向上しました。主な教訓としては、概念を検証するための早期の影響の価値、スケーラビリティのためにローカル制御ループを優先すること、および異なるタイムスケールで動作するメカニズムを採用することが挙げられます。この洗練されたQoSスタックは、Musselが極端で変動の激しいトラフィック条件下でも高速で信頼性の高い状態を維持することを保証します。

Airbnb は、進化するリアルタイムデータ需要に対応するため、コアとなるキーバリューストアである Mussel を V1 から V2 へ再設計しました。Mussel V2 は、V1 の運用上の複雑さ、容量の制限、および一貫性の問題を、クラウドネイティブな NewSQL バックエンドで解決します。主な改善点には、自動化された Kubernetes デプロイ、容量管理を改善するための動的なレンジシャーディング、および柔軟な一貫性オプションが含まれます。新しいアーキテクチャは、API 呼び出しを翻訳するためのステートレスな Dispatcher サービスと、耐久性のために Kafka を使用したイベント駆動型の書き込みパスを特徴としています。バルクローディング機能は維持され、ステートレスコントローラーとステートフルワーカーフリートにより高スループットを実現しています。自動化された TTL (有効期限) 切れは、トポロジーを認識するようになり、大規模でもより効率的になりました。V1 から V2 への移行は、ダウンタイムとデータ損失をゼロにするために、デュアルライトとシャドウリードを備えた複雑なブルー/グリーン戦略を採用しました。重要な教訓として、一貫性の複雑さの管理と、レンジベースのパーティショニングのためのプリスプリットの重要性が挙げられます。Kafka は、移行プロセス中に最終的な一貫性を維持する上で重要な役割を果たしました。Mussel V2 は、バルク取り込み、高速書き込み、低レイテンシ読み取りを単一のプラットフォームで効果的に統合し、エンジニアリングチームのデータインフラストラクチャを簡素化します。

Airbnbのデータ指向サービスメッシュである「Viaduct」が、オープンソース化されました。5年以上にわたり、AirbnbでのViaductの利用は著しく成長し、トラフィックは8倍に増加し、チーム数は2倍になりました。Viaductは、中心的なスキーマ、ホストされたビジネスロジック、および再入可能性という3つの主要な原則に基づいて開発が続けられています。中心的なスキーマは、会社全体のデータを統合し、Viaductを主要なデータメッシュとしています。サーバーレスプラットフォームによって実現された、ビジネスロジックをViaduct内で直接ホストすることで、開発者の運用を簡素化しています。再入可能性により、ホストされたロジックはGraphQLフラグメントとクエリを介して他のロジックと組み合わせることができ、モジュール性を維持しています。 最近の刷新である「Viaduct Modern」は、開発者向けのTenant APIをnodeとfieldの2種類のリゾルバに簡素化することで、過去の複雑さに対処しています。この近代化はまた、テナントモジュール性を導入し、「テナントモジュール」を単一のチームが所有し、GraphQLを介して構成されるスキーマとコードの単位として正式化しました。フレームワークのモジュール性も改善され、GraphQL実行エンジン、Tenant API、およびホストされたコード間のより強力な抽象化境界が作成されました。新しいエンジンAPIは動的型付けであり、Tenant APIは静的型付けであるため、独立した進化が可能です。 Viaductは、ClassicとModernの両方のTenant APIを新しいエンジン上で同時に実行することにより、段階的な移行を提供します。その他の改善点としては、可観測性の向上、スキーマファースト開発と直接バイトコード生成によるビルド時間の短縮、Kubernetesのスケーリングと影響範囲の軽減のためのディスパッチャなどがあります。Airbnbは、コミュニティからの貢献の恩恵を受けるためにViaductをオープンソース化し、大規模なGraphQLプロジェクトと、まだ発展途上のGraphQLプロジェクトの両方にとって価値があると考えています。Modern APIは現在アルファ版ですが、新しいエンジンは完全に本番環境で稼働しています。

Airbnbは、マイクロサービスベースのアーキテクチャにおけるモジュール性を向上させるため、データ指向のサービスメッシュであるViaductを開発しました。従来のサービスメッシュは手続き指向であるのに対し、Viaductはデータに焦点を当て、GraphQLスキーマを中心的な構成原理として使用しています。このスキーマは、型、クエリ、ミューテーションを定義し、サービス間の依存関係をコンシューマーから抽象化します。Viaductにより、データコンシューマーは直接的な依存関係なしに、複数のマイクロサービスから情報にアクセスできるようになり、アーキテクチャが簡素化されます。中心的なスキーマは、APIとデータベーススキーマの変更を容易にし、データの俊敏性を高め、調整作業を削減します。Viaductは、派生データのためにサーバーレス関数を統合し、マイクロサービスの数と複雑さを最小限に抑えます。graphql-javaで構築されたこのシステムは、きめ細かいフィールド選択、データ可観測性、リクエスト内キャッシングなどの機能を提供します。GraphQLエコシステムのツールを活用し、AirbnbのAPIトラフィックの大部分を支えています。Viaductは、大規模なサービス指向アーキテクチャで蔓延しているスパゲッティのような依存関係グラフに関連する課題に対処します。データ指向のアプローチへの移行は、データアクセスを合理化し、システム全体の保守性を向上させることを目的としています。アーキテクチャはクリーンなスキーマから始まり、多数のコアエンティティを含むように成長しました。すでに本番環境にデプロイされているこのソリューションは、AirbnbがSOAを進化させることにコミットしていることを示しています。

Airbnbは、4.5年かけて大規模なJVMモノレポをGradleからBazelへ移行しました。移行の主な理由は、Bazelの優れた速度、信頼性、統合されたビルドインフラストラクチャでした。Bazelのキャッシュとリモート実行により、ビルドおよびテスト時間が大幅に短縮され、開発者の生産性が向上しました。この移行は、非ザーメティックビルドとリソース競合に起因するGradleの信頼性の低さの問題を解決しました。AirbnbのViaductサービスを使用した概念実証は、Bazelの有効性を実証し、より広範な採用につながりました。重要なコンポーネントは、開発者の労力を最小限に抑え、共存するビルドシステムを維持するための自動ビルドファイルジェネレータでした。このジェネレータは、ソースファイルを効率的に解析し、依存関係のサイクルを管理し、きめ細やかなビルドグラフをサポートしました。移行には、マルチバージョンのサードパーティライブラリのサポートやデプロイメント互換性の確保といった課題への対応も含まれていました。最後に、厳格なテスト、特にサービスの起動および統合テストにより、Bazelでビルドされたデプロイメントの正しさが検証されました。全体的な結果として、開発者の満足度が向上した、劇的に改善されたビルドシステムが得られました。

Airbnbは、Istioサービスメッシュのアップグレードに14回成功し、数十のKubernetesクラスターと数千のVMにわたる数万のポッドを管理しています。彼らのアップグレードプロセスでは、ダウンタイムゼロと段階的なロールアウトを優先しており、ユーザーの介入なしに独立したアップグレードが可能です。アーキテクチャは、Istiod用の管理クラスターと複数のワークロードクラスターを含みます。アップグレードはカナリアモデルに従い、現在のIstioバージョンと新しいIstioバージョンを同時に実行します。 これは、コントロールプレーン（Istiod）とデータプレーン（istio-proxy）の更新を調整することによって達成されます。重要なのは、古いistio-proxyバージョンは新しいIstiodとは使用されず、アトミックに更新されることです。中央の管理ファイルであるrollouts.ymlは、名前空間全体でのIstioバージョンの望ましい配布を指示します。Kubernetesの場合、Krisprと呼ばれる社内ツールが、CIおよびポッドアドミッション中にIstioリビジョンラベルをデプロイメントに注入します。 このメカニズムにより、ワークロードは頻繁にデプロイされない場合でもアップグレードされます。仮想マシンについては、アップグレードはオンホストデーモンであるmxagentによって管理され、VMタグに基づいてアーティファクトをインストールします。中央コントローラーであるmxrcは、これらのタグをrollouts.ymlと整合するように更新します。MxrcはVMの正常性も監視し、制御されたアップグレードプロセスを保証します。このアプローチは、インフラストラクチャのアップグレードとアプリケーションのデプロイメントを効果的に分離します。Airbnbの保守性と安全性への継続的な投資は、これらの複雑で大規模なIstioアップグレードを可能にしました。

伝統的には、高価なスタンドアローン・サーバーとシャーディングを使用してデータベースのスケーリングを行ってきたが、このアプローチはデータの需要が増加するとメンテナンスが問題となった。クラウド環境で高可用性、低レイテンシー、スケーラビリティを実現しながら合理的なコストで水平スケーリング可能なオープンソース・データベースを実行することは大きな課題であった。Airbnbは、複数のKubernetesクラスターにわたる分散データベース・クラスターを展開することで、信頼性と運用性を向上させる革新的戦略を採用した。Kubernetes上でのステートフル・サービス zoals データベースの管理は、特にノードの置き換えやアップグレードに関する問題があるため困難である。Kubernetesがデータの配分に無知であるため、AirbnbはAWS EBSを使用してノードにストレージ・ボリュームをアタッチし、Kubernetes Persistent Volume Claimsを介して新しい仮想マシンに自動的に再アタッチできるようにした。カスタム・Kubernetes・オペレーターを開発し、ノードの置き換えイベントを管理することで、データベース・イニシエーション、プロアクティブ・インフラストラクチャー、計画外の障害に分類した。データベース・イニシエーションとプロアクティブ・イベントの場合、オペレーターはすべてのノードが稼働していることを確認し、ポッドの追放を調整して安全な削除を実現する。計画外の障害は調整できず、進行中のメンテナンスは、故障したハードウェアが修復されるまで置き換えをブロックすることで保護する。高可用性を実現するために、Airbnbは各データベースを異なるAWSアベイラビリティ・ゾーンにある3つの独立したKubernetesクラスターに展開し、問題の影響範囲を限定する。オーバープロビジョニングされたデータベース・クラスターは、1つのAZ、Kubernetesクラスター、あるいはゾーン内のすべてのストレージ・ノードがダウンした場合でも十分な容量を保証する。AWS EBSは、ノードの置き換えに対する高速な再アタッチと優れた耐久性を提供し、3つのレプリカでの高可用性クラスターを実現する。EBSでのレイテンシーのスパイクは、ストレージ・リード・タイムアウトの実装とレプリカからのリードを許可することで緩和し、クロス・アベイラビリティ・ゾーンのコストを避けることができる。さらに、ステイル・リードはリード・パフォーマンスを最適化する。このマルチ・クラスター・Kubernetes・ストラテジーは、AWS EBSとカスタム・オペレーターを活用し、クラウド環境でオープンソース・分散ストレージ・システムが高可用性、低レイテンシー、スケーラビリティを実現することを可能にすることで、ロバストなデータ・マネジメントを実現する。

2022年にAirbnbはSwiftUIを採用し、エンジニアの生産性を向上させたが、新しいパフォーマンスの課題を引き起こした。こうした問題に対処するために、Airbnbはパフォーマンスクリティカルなコードパターンの識別と検証のための新しいツールを作成した。同社のフィーチャーアーキテクチャーでは宣言型UIパターンと単方向データフローシステムを使用しており、これによりSwiftUIの採用を簡素化した。ただし、SwiftUIを使用したフィーチャーでは予想以上にパフォーマンスが低下し、SwiftUIのパフォーマンス特性を理解することがパフォーマンスの高いフィーチャーの構築にとって非常に重要となった。SwiftUIのビューディフイングアルゴリズムは、ビューのボディが再評価される必要があるかどうかを決定するものだが、しばしば見過ごされ公式ドキュメントにも記載されていない。このアルゴリズムはビューの各ストアドプロパティを比較するが、一般的なコードパターンでは混同を引き起こし、不要なビュー ボディの評価を引き起こす。対処として、Airbnbはビューに対してEquatable準拠を生成するための新しい@Equatableマクロを作成し、エンジニアが選択的にプロパティの比較を決定できるようにした。これにより、ビューがdiffableであり、後から回帰が生じるのを防ぐことができる。また、Airbnbはビュー ボディが複雑すぎて、小さなdiffableなピースにリファクタリングする必要がある場合を識別するためのカスタムSwiftLintルールを実装した。ビューを小さなピースに分割することで、SwiftUIは実際に変更されたビューの部分のみを効率的に更新し、フィーチャーの複雑さが増すにつれてパフォーマンスを維持することができる。

Airbnb のシステムレベルの負荷テストは、信頼性と効率性のために不可欠であり、ボトルネックの特定、容量の評価、パフォーマンスのベースライン確立、およびエラーの検出に役立ちます。 Impulse は、合成負荷の生成、依存関係のモック、本番環境からのトラフィックデータの収集を行うためのツールを提供する、社内向けの Load-Testing-as-a-Service フレームワークです。 Impulse は、ロードジェネレーター、トラフィックコレクター、依存関係モッカー、およびテスト API ジェネレーターの 4 つの主要コンポーネントで構成されています。 ロードジェネレーターを使用すると、サービスの所有者はコンテキストに応じた負荷テストを実行し、リクエストを動的に生成し、依存関係をモックすることができます。 トラフィックコレクターは、アップストリームとダウンストリームの両方のトラフィックをキャプチャし、Impulse が負荷テスト中に本番トラフィックを正確に再生できるようにします。 依存関係モッカーは、遅延を伴うダウンストリームの応答をモックし、サービス間の干渉を排除し、通信コストを削減します。 テスト API ジェネレーターは、CI ステージ中に HTTP API を作成し、負荷テストツールがこれらの合成 API にトラフィックを送信できるようにすることで、非同期フローを同期しているかのように実行できます。 Impulse は、手作業を最小限に抑え、Airbnb のオブザーバビリティスタックとシームレスに統合し、チームが潜在的な問題を積極的に解決できるように設計されています。 このフレームワークは肯定的なフィードバックを受けており、チームがサービスの潜在的な問題を特定し、解決するのに役立っています。 Impulse は現在、いくつかのカスタマーサポートバックエンドサービスで実装されており、会社全体のチームによるレビューを受けています。

Airbnbは、機械学習を活用してインタラクティブ・ボイス・レスポンス（IVR）システムを改善し、ユーザーをより理解し、エージェントの支援をより効果的に行えるようにしました。このIVRシステムは、リアルタイムで聞き取り、理解し、応答することで、通話者は問題を自然に説明し、即座にサポートを受けることができます。システムは、自動音声認識、問い合わせ理由の特定、言語モデルを使用して、ユーザーを理解し、エージェントを支援します。自動音声認識システムは、エラーを減らすように改善され、通話者の問い合わせの意図を特定するために、問い合わせ理由検出モデルが開発されました。ヘルプ記事検索システムは、ユーザーに関連情報を提供し、言い換えモデルは、ユーザーがエージェントに転送される前に解決策を理解していることを確認します。このシステムは、ユーザー満足度を向上させ、人的介入の必要性を減らし、より直感的な音声サポート体験を提供しています。

Airbnb は、ゲスト向けにリスティングの価値を決定するためにフレームワークを使用しており、リスティング生涯価値（LTV）を計算しています。このフレームワークには、ベースライン、インクリメンタル、およびマーケティング誘発インクリメンタル LTV が含まれます。ベースライン LTV は、機械学習とリスティングデータを使用して、365 日間の合計予約数を推定します。インクリメンタル LTV は、カニバリゼーションの課題に対処し、各リスティングによって追加される価値を推定します。マーケティング誘発インクリメンタル LTV は、Airbnb のイニシアチブがリスティングの価値に与える影響を測定します。ベースライン LTV の正確な測定は不可欠であり、時間の経過と共に行われるモデルのトレーニングと評価が必要です。インクリメンタリティを考慮するには、生産関数を推定して、供給と需要を予約に結び付ける必要があります。パンデミック中のような不確実性への対応には、実現した予約数に基づいて LTV の推定値を更新することが含まれていました。この LTV フレームワークは、Airbnb が価値のあるリスティングを特定し、供給戦略に役立て、社内イニシアチブを評価するのに役立ちます。このアプローチは、Airbnb Experiences など、他の分野にも拡張できます。フレームワークの継続的な開発は、ホストとゲストの両方の体験を向上させることを目指しています。

Airbnbの検索機能は、ゲストが理想の滞在先を見つけるのを助ける上で重要な役割を果たします。しかし、利用可能な家が多く、検索クエリが複雑であるため、難しいタスクです。この課題に対処するために、Airbnbは、最初の候補となる家の集合をより小さなプールに絞り込むために、埋め込みベースの検索（EBR）システムを構築しました。EBRシステムは、3つの重要なコンポーネントで構成されています。トレーニングデータの構築、モデルのアーキテクチャの設計、およびオンライン提供戦略の開発です。トレーニングデータパイプラインは、コントラスト学習を利用して、家と検索クエリを数値ベクトルにマッピングします。モデルのアーキテクチャは、伝統的な2タワーネットワーク設計に従います。1つのタワーは家のリストに関する機能を処理し、もう1つのタワーは検索クエリに関する機能を処理します。リストタワーは、オフラインで毎日計算され、オンライン遅延が軽減されます。オンライン提供のために、Airbnbは近似最近傍隣接（ANN）ソリューションを探索し、速度とパフォーマンスのバランスが優れているため、逆ファイルインデックス（IVF）を選択しました。IVFソリューションは、事前にリストをクラスタリングし、クラスタ割り当てを標準の検索フィルターとして扱うことで、上位クラスタから家を取得します。EBRシステムは、A/Bテストで統計的に有意なブッキングの増加につながり、検索時にクエリコンテキストを効果的に組み込み、家のランキングをより正確に行うことができました。このシステムは、検索とEメールマーケティングの両方のプロダクションで完全に導入されています。

Airbnbは、LLMドライブンアプローチを使用して、EnzymeからReact Testing Library（RTL）への約3,500のReactコンポーネントテストファイルの移行を達成した。このタスクは、当初1.5年の労力が必要と推定されていたが、わずか6週間で完了した。移行には、オリジナルのテストの意図とコードカバレッジを保持したままテストファイルのリファクタリングが含まれていた。自動化されたパイプラインを構築し、バリデーション、リファクタステップ、およびリトライループを実装した。LLMには、コンポーネントコードや関連するテストなど、より多くのコンテキストを提供し、成功率を向上させた。「サンプル、チューン、スイープ」アプローチを使用して、プロンプトやスクリプトを改善し、完了率を75%から97%に向上させた。自動化は、移行の大部分を効率的に処理し、わずかな割合を手動での修正に残した。このプロジェクトは、テストの意図とコードカバレッジを維持し、手動での移行よりもはるかに速くてコスト効果的であった。この経験は、大規模なコード変換に対するLLMの力を示している。Airbnbは、開発者の生産性向上のためにLLMの使用を拡大する計画を持っており、複雑な問題を大規模に解くことを愛するエンジニアを募集している。

Airbnbは、地図インターフェースのランキングアルゴリズムを改善し、ゲストとホストをよりよく結びつけるようにしています。初めのランキングアルゴリズムは、予約確率に基づいていましたが、ピンの注意が等しく分布する地図ではこのアプローチが機能しません。ユーザー体験を向上させるために、Airbnbは、異なるユーザー注意モデルをテストしました。例えば、地図ピンの数を制限し、予約確率に基づいて2つのピンの階層を作成するなどです。これらの変更は、予約とユーザー満足度の両方で顕著な改善をもたらしました。同社はまた、最高の予約確率を持つ物件をハイライトするために地図を再センターするアルゴリズムを開発し、予約の向上と地図の移動の減少を遂げました。ただし、地図上で利用可能な物件の全範囲を表現することはまだ課題で、将来的にこれを改善することを目指しています。

Airbnbは、スペインのバルセロナで開催された2024年のKDDカンファレンスに大きな存在感を示した。フルADSトラックペーパーが3件、ワークショップが1件、ワークショップペーパーと招待講演が7件、メインカンファレンスの論文に採択された。研究テーマは、ディープラーニング＆検索ランキング、オンライン実験＆測定、双方向マーケットプレイスに及んだ。双方向マーケットプレイスの最適化に関するワークショップへの企業の貢献は、これらのプラットフォームの生産者と消費者に対するコンテンツランキング、レコメンデーションシステム、データマイニングの進化について議論した。Airbnbのゲストの意図モデリングによるパーソナライゼーションの研究は、ディープラーニングアプローチを使用して旅行プランを予測し、複数のユーザー意図シグナルを生成する。同社はまた、ゲストの需要理解に関する論文を発表し、経済モデリングと因果推論技術を組み合わせて、ゲストセグメントの価格感度を推定した。

Vijaya Kazaは、Airbnbのチーフ・セキュリティ・オフィサー兼Trust and Safetyのエンジニアリング・ヘッドです。彼女は、コミュニティを守り、インフラストラクチャーをセキュアにする技術を開発するチームを率いています。また、Airbnb Techのダイバーシティ・カウンシルの執行共同スポンサーも務めています。 Vijayaは、インドで大きな家族で育ち、学業的に秀でることが期待されていました。彼女は、大学で電気工学を学び、理科と数学に強い愛着を抱くようになりました。大学卒業後、Ciscoでソフトウェア・エンジニアとしての仕事に就き、偶然セキュリティ・フィールドに踏み入ることになりました。彼女は、Ciscoで17年間働き、10億ドルのセキュリティ・プロダクト・ポートフォリオの製品開発を率いました。後には、FireEyeとサンフランシスコのスタートアップであるLookoutで、モバイル・セキュリティに焦点を当てた仕事をしました。 Vijayaは、AirbnbのCSO役職にアプローチされ、当初は躊躇しましたが、会社のビジョンとミッションに感銘を受けました。彼女は、2019年にAirbnbに加入し、会社のユーザー・エクスペリエンスの向上とミッション・ドリブン・アプローチに惹かれました。 Vijayaは、2つのチーム、Trust and SafetyとSecurityを率いています。これらのチームは、ユーザーとプラットフォームを守るという共通のミッションを持っていますが、異なる技術、脅威、焦点領域があります。仕事の外では、Vijayaは、即興コメディーを学びました。この経験から、リーダーシップに関する貴重な教えを受けました。例えば、状況に応じて即座に対応し、新しいシナリオに対処する能力を学びました。彼女は、プロフェッショナル・セットバックに直面した際には、集中し、冷静さを維持し、前向きに進むことをアドバイスします。

Airbnbは、データ駆動型のセグメンテーションを使用して、ホストの利用可能なパターンを理解しています。このプロセスには、利用可能な割合、連続性、季節性を分析して、類似したプロファイルを持つホストを区別することが含まれます。K-meansクラスタリングアルゴリズムを適用することで、Airbnbは、ホストの利用可能なパターンに基づいて8つの異なるクラスターを特定します。これらのクラスターには、「常にオン」、「短期的な季節性」、「イベントに動機づけられた」などのユニークな特徴と嗜好を持つものがあります。同社は、これらのセグメントをA/Bテストで検証し、既知の属性と関連付け、UXリサーチを実施して、現実世界の行動と一致することを確認します。このセグメンテーションモデルは、決定木アルゴリズムを使用してすべてのリストにスケールアップされ、データウェアハウスに統合されて、さまざまなチームで使用されます。このアプローチにより、Airbnbは、ホストをよりよくサポートし、全体的なユーザーエクスペリエンスを改善するための、ターゲットに絞った戦略、製品、メッセージングを開発できます。

Airbnbは、ユーザーの体験をパーソナライズ化することで向上させるために、User Signals Platform（USP）と呼ばれるストリーム処理プラットフォームを開発しました。このプラットフォームは、ユーザーのエンゲージメントデータを利用して、予約プロセス中にカスタマイズされたインタラクションを提供します。データパイプラインレイヤーとオンラインサービングレイヤーで構成されており、Flinkストリーミングを使用してほぼリアルタイム処理とバッチ処理を実行し、データの修正とバックフィルを行っています。USPは、ユーザーシグナル、ユーザーセグメント、セッションエンゲージメントなどのさまざまなユーザーイベント処理をサポートしています。また、イベントレイテンシ、インジェストレイテンシ、ジョブレイテンシ、トランスフォームレイテンシなどのメトリクスを使用して、ストリーミングジョブのパフォーマンスを測定します。プラットフォームは、開発者がストリーミングコンポーネントを心配せずにトランスフォームとユーザーセグメントを定義できるように設計されています。Flinkジョブの安定性を向上させるために、Airbnbは、タスクマネージャーが失敗した場合に継続的な処理を保証するために、スタンバイタスクマネージャーを使用しています。

Airbnbは、ゲストの体験を向上させるために、AIが駆動する写真ツアー機能を開発しました。この機能は、Vision Transformersを使用して、16つの異なる部屋タイプに分類し、リストの写真を組織化します。モデル精度を向上させるために、Airbnbは、事前学習、多タスク学習、アンサンブル学習、知識蒸留を採用しました。事前学習プロセスでは、数百万のAirbnbリスト写真でVision Transformerモデルを学びました。多タスク学習は、視覚的な解釈能力を向上させるために多様なデータセットを使用しました。アンサンブル学習は、複数のモデルの長所を組み合わせて、ロバストな予測を実現しました。知識蒸留は、精度を犠牲にすることなく効率的にデプロイメントを可能にしました。AIが駆動する写真ツアーは、Airbnbの2023年冬リリースの一環として導入され、ユーザー体験の向上のためにモデルを継続的に改善しています。

Airbnbは最近、GoogleのオープンソースビルドツールであるBazelを、バックエンド、Web、iOSプラットフォーム全体のユニバーサルビルドシステムとして採用しました。11百万行を超えるコードを持つ大規模なWebモノリポジトリは、メンテナンスが困難でスケールが悪い独自のビルドスクリプトとキャッシングロジックを抱えていました。これらの問題に対処するために、AirbnbはBazelに移行しました。Bazelは洗練された構造、並列処理、キャッシング、パフォーマンスを提供しました。 移行プロセスは2021年に開始されましたが、Google以外のWebでのBazelの導入に関する業界の先例はありませんでした。チームはリモート環境への大きなファイルの転送時のパフォーマンスの問題を克服し、パフォーマンスを改善または維持し、移行中にモノリポジトリに貢献する開発者の影響を最小限に抑えることを含む移行の原則を確立しました。 リポジトリをBazelに準備するために、チームはサイクルブレーキングと自動BUILD.bazelファイルの生成を実行しました。また、CIジョブをBazelに移行し、タイプチェック、リンティング、ユニットテストから始めました。チームはTypeScript、ESLint、Jestを有効にし、キャッシングを導入して入力サイズを削減し、パフォーマンスを向上させました。 後戻りを防ぐために、チームはテストを「隠し」から「必須」に変更し、Jestの設定を置き換えるテストを実行しないことで、単一の真実の源を確保しました。また、テスト実行時間、コードカバレッジの統計、失敗率などのメトリックを使用して、Bazelの移行の準備ができているかどうかを判断するために、Bazelの前後を比較するスクリプトを書きました。 CIの移行と並行して、チームは開発者がCIの失敗を再現し、繰り返し処理できるように、開発者がローカルでBazelを実行できるようにしました。チームは、既存の開発者の体験とパフォーマンスに匹敵する、またはそれを上回るローカルのBazelの体験を提供し、開発者が既存のツールを使用し、Bazelを有効にすることができるようにしました。

Airbnbは、世界中で人々の旅行の仕方を変革させましたが、インベントリーの多様なロケーションとプロパティータイプが増えるにつれて、ゲストが検索結果で関連するオプションを見つけることが困難になっていました。この課題に対処するために、Airbnbは、シンプルなヒューリスティックから高度な機械学習と強化学習の技術に移行し、ロケーション検索プロセスを変革しました。まず、Airbnbは、検索の種類に基づいてマップのエリアを定義するヒューリスティックを使用していましたが、這らのヒューリスティックは、異なる検索タイプや新しいデータに対応できませんでした。 次に、Airbnbは、統計学を使用してロケーション検索を改善し、各旅行先のデータセットを構築し、ゲストがその目的地を検索する際に予約した物件の場所を記録しました。ただし、統計的なアプローチもまた制限があり、特定の検索パラメータにかかわらず、すべての検索結果を同じように扱いました。このため、Airbnbは、ロケーション検索がより高度な技術、例えば機械学習を必要かもしれないと信じるようになりました。 Airbnbは、多くの検索パラメータ、例えば宿泊人数や滞在期間を学び、各検索に対してより関連するマップのエリアを予測することができる機械学習モデルを構築しました。この機械学習システムは、予約された物件のリコールを7.12%向上させ、検索結果のマップのエリアのサイズを40.83%縮小させ、結果的にプラットフォーム上のキャンセルされていない予約者が累積的に1.8%増加しました。 Airbnbは、次に強化学習をロケーション検索プロセスに導入し、ゲストのインタラクションから継続的に学び、予約された物件の行動に基づいて検索結果のマップのエリアを調整することができます。この強化学習システムは、旅行の少ないロケーションをより多く探検し、頻繁に検索されるロケーションをより少なく探検することに成功し、結果的にキャンセルされていない予約者が累積的に0.51%増加し、5スターの旅行の評価が0.71%向上しました。 Airbnbがシンプルなヒューリスティックから高度な機械学習と強化学習のモデルに移行する過程は、大規模な企業が運営する複雑なシステムを変革するデータドリブンアプローチの力を見せています。この変革は、累積的にキャンセルされていない予約者が2.66%増加する大きな成果をもたらしました。

Airbnbの自動化プラットフォームv2は、会話型AIプラットフォームであり、エマージングの大規模言語モデル(LLM)アプリケーションをサポートすることを目的としています。このプラットフォームでは、開発者が顧客サポートの効率化とレスポンスタイムの向上を目的としたLLMアプリケーションを構築することができます。このプラットフォームには、チェーン・オブ・ソート・ワークフロー、コンテキスト・マネジメント、ガードレール・フレームワークなどの複数の主要コンポーネントが含まれています。チェーン・オブ・ソート・ワークフローでは、LLMを推論エンジンとして使用し、どのツールを使用し、どの順序で使用するかを決定します。コンテキスト・マネジメントでは、LLMが必要なコンテキスト情報にアクセスできるようにします。一方、ガードレール・フレームワークでは、LLMとのコミュニケーションを監視し、LLMが有益で関連的であり、倫理的であることを確保します。このプラットフォームは、変革的な技術を搭載し、チェーン・オブ・ソート・ツールの機能を拡張し、LLMアプリケーションのシミュレーションを調査するために進化しています。

Riverbedは、Airbnbのテックスタックの一部で、レコードストアから読み込み最適化されたストアを更新するデータ消費を最適化します。ラムダーアーキテクチャーを使用し、ストリーミングコンポーネントとバッチコンポーネントがあります。ストリーミングアスペクトは、チェンジデータキャプチャー（CDC）イベントからマテリアライズドビューを構築することに焦点を当てています。Notification Pipelineは、通知イベントを消費し、依存するデータソースを照会してマテリアライズドビューを構築し、シンクストアに書き込みます。Join操作は、DAGのような構造を使用してデータソースを効率的に結合し、JoinConditionsDagをメタデータに、JoinResultsDagを結果の保存に使用します。Stitch操作は、結合された結果を使用可能なモデル、StitchModelに変換します。Riverbedは、Apache HiveやKafkaを含む複数のシンクをサポートし、柔軟性を提供します。ストリーミングシステムは、CDCイベントからマテリアライズドビューを効率的に更新し、スケーラビリティ、効率的なデータフェッチ、フィルタリングと検索機能の向上を可能にしています。次のブログポストで話題にするSource Pipelineは、並行処理とバージョニングにおいて重要な役割を果たします。DAGベースのデータ構造を活用することで、Riverbedはストリーミングデータの結合を最適化し、メモリーの使用量を削減し、効率を向上させています。

Airbnbのメディアチームは、グループ旅行の予約に対するポストカード生成システムを開発し、新しい目的地マッチングアルゴリズムを活用しました。このシステムは、ローカライズされたテキストレイアウト、デザインの柔軟性、そして高性能が必要でした。ローカライズされたテキストレイアウトに対処するために、上位の予約目的地向けの翻訳を手動でフォーマットする妥協がなされました。柔軟なテンプレートデータモデルがテキストの位置と色の設定を簡単に構成できるようにしました。パフォーマンスを向上させるために、非同期的なポストカード作成フローが実装され、ラテンシーの最小化と既存のメディアサービングインフラの活用が図られました。目的地とポストカードをマッチングさせるためのアルゴリズムが開発され、リスト固有のアートワーク、人気の目的地、タクソノミータグ、デフォルトのフォールバックが考慮されました。上位の目的地向けのポストカードの事前生成が、汎用的なポストカードの使用を最小限度に抑えることに貢献しました。このソリューションは、Airbnbのグループ旅行体験を向上させるメディア能力の力を見せています。

Airbnbのデータ分類システムは、個人データを特定し保護することで信頼とコンプライアンスを確保します。このシステムは3つの柱で構成されています：カタログ化でデータを探し出す、検出で個人データを特定し、和解で分類を確認します。自動検出はメタデータ、コンテンツ、機械学習を使用して個人データを分類します。人間の入力が分類を確認し、誤検出を最小化し、解決を促進します。品質メトリクスは、リコール、精度、速度を評価し、効果を確保します。チャレンジとしては、後処理分類、不一致な分類、プロセスコストがあります。Airbnbは、データスキーマの作成時点でデータ分類を統合することでこれらのチャレンジに対処することを提唱します。このアプローチは、データ所有者が自分のデータを管理し、注釈することを可能にし、ラインナジ情報を使用した自動注釈で手動的な労力を削減します。Airbnbのデータ分類システムは、似たチャレンジに直面する組織に対し、包括的なフレームワークを提供し、データ保護とコンプライアンスを促進します。

Airbnbのストリーミング処理アーキテクチャは、Hadoop YarnからKubernetesに進化し、FlinkがSpark Streamingに代わって主なプラットフォームとなった。移行には、ジョブスケジューラとしてのAirflowを廃止し、軽量なストリーミングジョブスケジューラを導入することが含まれた。Kubernetesへの移行により、開発者の体験が改善され、モニタリングが強化され、サービスディスカバリーが合理化された。現在のアーキテクチャは、5つの主なコンポーネントで構成されている。ジョブ設定、イメージ管理、CI/CD、Flinkポータル、Flinkジョブランタイムである。Kubernetesベースのアーキテクチャの利点には、開発者の速度の向上、ジョブの可用性と待ち時間の改善、コストの削減が含まれる。将来の作業は、ジョブの可用性の向上、ジョブの自動スケーリングの実現、Flink Kubernetesオペレータの探索に焦点を当てている。

Airbnbのフロントエンドは、React Upgrade Systemを使用してReact 18にアップグレードしました。これにより、長時間の機能ブランチを必要とせずに、段階的かつテスト可能なアップグレードが可能になります。 モジュールエイリアシングと環境ターゲットにより、Reactのバージョンが別々のビルドアーティファクトとランタイム環境に分割されます。 TypeScriptの不一致は、シム、タイプ増強、段階的なTypeScriptエラーの修正を使用して処理されました。 包括的なテストには、ビジュアルリグレッション、統合、単体テストが含まれ、単体テストはReact 16と18の両方で実行されました。 段階的なロールアウトにより、React 16と18の環境へのトラフィックが制御され、内部テストと段階的なサーフェスアップグレードが可能になりました。 このシステムにより、React 18を指さずにReact 19のカナリア版のリリースをテストすることができました。 React 18の新しいルートAPIやコンカレントレンダリングなどの機能を採用した後、パフォーマンスの向上が観察されました。 このシステムは、継続的なアップグレードの取り組みを促進し、大規模な、一時的な変更を回避します。 Reactチームの後方互換性への取り組みにより、このアップグレードアプローチが可能になりました。 Airbnbのフロントエンドは現在、React 19ベータを実行しており、将来のReactアップグレードのための準備が整っています。

Airbnbは、ウェブアクセシビリティを向上させるために、テキストが200%まで拡大された状態で読みやすくなるようにすることに焦点を当てました（テキストサイズの変更）。デスクトップ上では効果的ですが、モバイルデバイス上ではビューポートが限られているため、ブラウザのズームが問題となった。Airbnbは、ページのズームとは独立してテキストサイズを調整するフォントスケーリングを選択しました。 このアプローチで、テキストサイズが一貫してスケールし、レイアウトの他の要素には影響しません。デザイナーがデザイン段階でフォントスケーリングをシミュレーションできるツールも提供し、rem単位の移行を簡単化しました。 2つのCSS-in-JSシステム、React-with-StylesとLinaria、での移行の管理も、新たな課題を生みました。Airbnbは、Linariaのカスタムプロパティサポートとpost-CSSプラグインを使用し、ほとんどのフォント関連プロパティを変換しました。px単位を必要に応じて使用できるように、逃げ道も提供しました。 これらのアクセシビリティ向上の実装により、「テキストサイズの変更」に関する報告された問題の数が大幅に減少し、視力障害者らのユーザーエクスペリエンスが向上しました。Airbnbは、ユーザーのニーズを重視し、ベストプラクティスを採用することで、包括的なウェブデザインに対するコミットメントを示しました。

2023年、Airbnbは、ゲストとホストの接続を強化するためにパーソナライズされたプロフィールを通じてホストのパスポートを導入しました。このパスポートは、検索結果に表示され、ゲストが予約する前にホストとその住む空間について学ぶことができます。アニメーションを作成するために、Airbnbは、UIKitと宣言的な遷移フレームワークを使用しました。パスポートは本のように回転し、ページをめくる効果を実現するために透明なビューを使用します。アニメーションフレームワークとの統合により、検索結果からモーダルビューへのスムーズな遷移が可能になります。アニメーションは、同期された動き、回転、影の各々が独自のタイミング曲線を持っています。Airbnbは、現実的な弾性を実現するためにスプリングタイミングを使用しましたが、モーダル遷移のタイミングと調整するように注意深く調整しました。結果として、Airbnbの体験を向上させるシームレスで視覚的に魅力的なアニメーションが生み出されました。

Brandometerは、Airbnbの自然言語理解技術で、ソーシャルメディアデータからブランドイメージを定量化します。ブランドイメージを測定するために、単語埋め込みとコサイン類似度を使用して、単語と「Airbnb」間の関連性を計算します。ノイズとスパースの影響を軽減するために、データはクリーニングと処理が行われます。さまざまな単語埋め込みモデルが探検され、DeBERTaが小さなデータセットで最も効果的に機能します。スコアの安定化のために、平均化とランキング技術が採用されます。校正されたスコアは、異なる期間の平均分散（AVADP）などのメトリックを使用して評価されます。Brandometerは、業界分析、浮上する認識の特定、キャンペーンの影響の追跡に有用です。将来的には、コンテンツのセグメント化の改善とデータ基盤の強化が含まれます。ソーシャルメディアからブランドイメージを捉えることで、Brandometerは顧客体験の向上のための有価な洞察を提供します。

AirbnbのJetpack Compose用スクリーンアーキテクチャであるTrioは、Mavericksを利用して状態管理を行っています。TrioのPropsは、ViewModel間の簡素化されたタイプセーフな通信を容易にします。Propsは、親から子に渡されるデータクラスで、Kotlinのプロパティを含み、Trioのライフサイクル全体で動的なデータ交換を可能にします。親のTrioは、子TrioのPropsを定義し、互換性とコンパイル時正確性を保証します。Propsには、ラムダ式を含めることができ、子スクリーンが親に通信することができます。Propsを渡すには、親のTrioはlaunchChildInitializer関数を使用し、子Trioのライフサイクルを管理し、プロセス再作成後にPropsを再確立します。子ViewModelは、updateStateFromPropsChange関数を使用して、Propsの変更に応じて状態を更新します。非状態Propsの値は、propsプロパティを介してアクセスできます。TrioのScreenFlow機能は、スクリーンスタックの管理を自動化し、Propsを介して子スクリーン間で状態とナビゲーション関数を共有します。AirbnbのAndroidチームは、Trioを成功裏に実装し、開発サイクルの高速化とコード品質の向上を実現しました。

オープンソースのML機能プラットフォームであるChrononは、MLプラクティショナーが多様なデータソースを利用して機能変換を行うことを可能にします。データエンジニアリングの複雑さを簡素化し、低遅延の提供、可視化ツールや管理ツールを提供します。Chrononは、オフライントレーニングとオンライン推論の両方をサポートする機能を1回定義することで、MLプラクティショナーを支援します。グループ化、結合、または取得APIなどのコンポーネントを備えており、高い精度で機能を集約、組み合わせ、取得することができます。Chrononのバックフィルプロセスは、特定の時点での正確性を確保し、データの偏りを効率的に処理します。また、取得APIを通じて低遅延の機能提供を行い、オンラインとオフラインの整合性を監視します。Chrononのビジョンは、機能エンジニアリングの効率を高め、計算コストを削減し、機能の作成をよりアクセスしやすくすることです。Chrononのロードマップは、反復と計算コストを削減し、機能の作成を簡素化し、機能表現のための自然言語処理を探求することを目指しています。

シリーズのパート2では、Android向けのComposeベースのアーキテクチャーであるTrioについて議論します。Trioは、ViewModelの状態にTriosを保存することでナビゲーションを簡略化し、簡単なナビゲーション制御を可能にします。ViewModelは、1つの場所でデータとナビゲーションを更新できるため、非同期ナビゲーション変更が可能になります。ナビゲーションスタックは、ViewModelのチェーンとその状態によってモデル化され、対応するCompose UI階層が作成されます。Triosは、ネストされたスクリーンやセクションを含む様々なUI要素を表現できます。モジュール化構造には、Trioスクリーンとナビゲーションを含むフィーチャーモジュール、およびルーターを定義するナビゲーションモジュールが含まれます。ルーターは、型安全性を確保し、循環依存関係を削減します。Routerクラスは、Trioのインスタンス化と、新しいアクティビティーの開始のためのインテントの作成を支援します。新しいアクティビティーでTrioを開始するとき、インテントからTrioインスタンスが抽出され、アクティビティーのコンテンツに表示されます。Trioのナビゲーションシステムは、ルーター上的のResultタイプを使用して、新しいアクティビティーの結果を返すことをサポートしています。

「Trio: Jetpack Compose アプリケーションの Android アーキテクチャーフレームワーク Trio は、Mavericks ステートマネージメントライブラリを基盤にして、Jetpack Compose アプリケーションの Fragment ベースのアーキテクチャーの課題に対処するために構築されたフレームワークです。 Trio は、「Trios」と呼ばれる自己完結型のブロックを導入しています。これらのブロックは、ViewModel、State、および UI で構成されています。Trios は、ネストしてナビゲーションヒエラルキーを形成することができます。 Trio は、Trios 間の型安全なナビゲーションと通信を強制します。これは、モジュールの境界内外での両方において適用されます。 各 Trio には、独自の ViewModel があり、Mavericks リデューサーを使用してステートの変更を管理します。 UI は、ViewModel から最新のステート値を受け取り、適切にレンダリングします。 イベントは、ViewModel にルーティングされ、さらなるステートの更新を維持するために unidirectional データフローを維持します。 Trios は、モックされた引数、State、および Props で個別にインスタンス化することで、コントロールされたテスト環境を提供します。 Args は、静的な入力データを提供し、Props は、動的な入力データを提供します。 リフレクションとアシストされたインジェクションを使用して、UI クラスと ViewModel クラスの作成を自動化し、ボイラープレートを削減します。 Trio は、Compose UI の境界とステートの作成および管理を標準化し、型安全性とテスト可能性を向上させます。」