[レポート] LINEの独自LBaaSを支えるソフトウェアエンジニアリング #linedevday_report

LINEの独自LBaaSを支えるソフトウェアエンジニアリング

2019年11月20日（水）・21日（木）にグランドニッコー東京 台場でLINEのデベロッパーカンファレンス「LINE DEVELOPER DAY 2019」が開催されました。

• LINE DEVELOPER DAY 2019

本記事は、セッション「LINEの独自LBaaSを支えるソフトウェアエンジニアリング」をレポートします。

スピーカー

• 早川 侑太朗 [LINE ネットワーク開発チーム インフラエンジニア]

セッション概要

2017年12月よりLINEのプライベートクラウドでは自社開発のLBaaS (Load Balancer as a Service) が本番環境で稼働しています。リリースから約2年、年々適用範囲が拡大し、現在ではLINEメッセージングサービスのサーバを収容するなど、非常に重要なコンポーネントになりました。中でもL4ロードバランササービスはパケットの処理を行う基盤部分からソフトウェアで独自開発しています。本セッションでは既存のアプライアンス製品やオープンソースソフトウェアがある中で独自開発に至った経緯、Linuxの高速パケット処理基盤であるXDP (eXpress Data Path) を用いたロードバランサのアーキテクチャ、高いパフォーマンスを保ちつつ積極的に新しい機能を取り入れるための自動テストの仕組みづくりなどについてご紹介します。

スライド

レポート

自己紹介

• 今年新卒で入社
• ロードバランサーを担当

Verdaについて

• 2016年にローンチ
• LINEのPrivate Cloudのコンポーネント
• Open Stackベース
• 多くのLINEサービスがVerdaで動いている
• 1400のハイパーバイザ
• 1年間に2万個のVMが作られる
• マネージドのミドルウェアを乗せて運用している
• ロードバランサーは、コンピューティングネットワークのIaaSの部分と言える

LBaaS

• LBaaSを使うことで、あたかもそのサービスのためのものと思えるような感覚で使えること
• 開発や運用を行うことがミッション

ロードバランサーの2つのタイプ

• 様々なサービスをやっているので
• L7LB
  • いわゆるリバプロ
• L4LB
  • アプリより下のレイヤーでTCPコネクションベースで負荷分散
• L7はニッチな機能を備えている
  • 一般的なWebアプリではほとんどのユースケースで活かせる
• L4は
  • パフォーマンスが求められる場合
  • L7だとオーバーヘッドが大きいので

よく目にするユースケース

• メッセンジャー
  • テキストメッセージ
  • ビデオ
  • アイコン
  • 広告
  • などなど…

LBaaSを開発しているということ

• 買ってきてプロビジョニングしているわけではない
• 独自にソフトウェアを開発して運用している
• ほぼスクラッチで開発している
• なぜ既製品を使わないのか？
  • 様々な問題を鑑みている
    • 運用コスト
    • スケーラビリティ
    • アベイラビリティ
• 以前は既製品で運用していた
  • 1 + 1、Active and Standby
  • サービスの規模が拡大するにつれて問題が浮き彫りに
    • 人間がマニュアルで運用していた、自動化されていない
    • リクエストから1 - 2日で開通するなど
    • デベロッパーにとってストレスフル
    • 無視できないものになってきた
  • スケーラビリティとアベイラビリティ
    • どのサーバーにどのクライアントが繋がっているのか、セッションテーブルで記録する方針があり、それを採用していた
    • 弱点があった、セッションテーブルの容量が枯渇する問題
    • 同時に接続できる数が制限される
    • TCP SYN Floodアタックもあり、意図的に枯渇させられる
• 根本的な見直し
  • 3つ
    • デベロッパーとオペレーターの両方の負荷を軽減する
      • APIを使うことですぐに手を入れられるようにする
    • トラフィックに応じてスケールできる
      • スケールアウトできること
    • 冗長化でき、障害時に影響範囲を可能な限り小さくできる
  • 参考
    • Google, Facebookの設計を参考にした
    • 論文の発表を多く行われていた
    • 5年以上の運用経験から導き出された知見、ノウハウが非常に参考になった
  • 新しい
    • Multi Tierのロードバランサー
      • 複数のロードバランサーを多段で繋げるアーキテクチャ
      • N+1で冗長化する構成
      • 各Tierでスケールアウトできる
    • L4はステートレスで負荷分散するように変更
      • 問題視されていたセッションテーブル問題を解決
    • 汎用的なサーバーにソフトウェアをデプロイする方式に決定
      • 単価が安く、コスト効率が良い
      • 1Reあたりの性能単価は役10分の1にするkとができる
      • 普通のサーバーとして運用できる（DockerやAnsibleなどのノウハウを活かせる）

Controller Design

• Pythonで実装
• REST APIでLBの作成や削除を自動で行う
• オペレーターの作業コストを下げる
• デベロッパーが欲しいタイミングで好きに作れるメリット
• VerdaのUIチームにより作られたかっこいいGUIで作成できる
• VMをLBに紐づけたり、ドメイン名をつかたりがシームレスにできるようになっている
• リビジョン管理
  • LBの設定をバージョン管理する
  • 設定を誤った場合、すぐにロールバックするなど

L7 LB Architecture

• k8sを使って構築
  • コンテナデプロイ、サービスディスカばり、オートスケーリングを使うことが目的
  • 高いアベイラビリティを実現するための工夫をしている
    • 複数のリージョンに配置
      • 1つのクラスタで障害が起きた場合に続けることができる
      • 失敗した場合の障害のリスクを避けるため
    • Verdaで使われているVMを使っている点
      • LBの管理者がリソース配置に気を配る必要がない
      • 物理的な作業を行わずに済む
    • VIPアドレスの分散
      • 一定のポリシーにしたがって、分散されてアサインされる
      • 1つのVMにトラフィックが増えた場合でも対応できる
      • 同じ役割のコンテナを複数のノードに分散する

L4 LB Architecture

• OpenStackと外れたスタッフで組んでいる
• 冗長化はL7と一緒
• オーバーヘッドを避けるために物理サーバーで動かしている
• 様々な理由からフルスクラッチ
  • パフォーマンス
  • 単体のパフォーマンスはどうしても劣ってしまう
  • L4はパフォーマンス重視
  • 秒間700万パケットを処理できる要件が設定されていた
  • この時、LinuxにXDPというフレームワークが用意された
    • 非常に高速にパケットを裁くことができる
    • C言語で書くことができる（わずか500行で実現できた）
    • 本職のCプログラマではない場合でも便利な機能がある
      • メモリアクセス違反を静的に検証できる
      • Cで書かれたプログラムの保守派大変だが、致命的なバグを埋め込む心配はなくなる
  • パフォーマンスをキープすることも重要
    • 新機能によってパフォーマンス低下した場合はいち早く気づける必要がある
    • CI/CDを行なって、継続的にパフォーマンス監視を行う必要がある
    • パフォーマンステストの再現性を高めるため、自動化を行なった
      • 開発者が各自やってしまうと。平等に比較できなくなる
    • 開発のフローに乗せられるように、GitHubのプッシュをトリガーに発動
    • 様々なテストシナリオを実行
    • レポートはGitHubのPRに貼り付けられる

最近の取り組み、機能追加の実装

• L4LBのステートレス化による問題
  • Gracefulシャットダウンできない
  • フェイルオーバーが難しくなる
• 原因は実装による
  • IPアドレス、ポート番号、ハッシュ表を引いてサーバーを決定するアルゴリズム
    • この状況でサーバーをシャットダウンした場合、ハッシュ表を更新しなければいけない
    • すでにセッションがある場合は終わってからシャットダウンできない
      • TCPコネクション情報が残っていないため（ステートtレスなので）
• 非常によく知られている問題なので
  • Consistent Hashingによりある程度避けられることがわかっていた
  • しかし、信頼線が不十分なユースケースがあった
    • メディアは維新への適用
      • 画像をアップロード途中でコネクションが切れる
      • 動画視聴中に切れるなど
    • 広告への嫌煙
      • 広告が表示できなくなる
• セッションキャッシング
  • まずセッションキャッシュを検索
  • ヒットした場合は転送
  • ない場合は転送先サーバーを調べてキャッシュに記録する
  • しかしセッションテーブルと同じ枯渇問題と同じ問題を抱えている
    • Stateless vs Statefulという構図になる
• ソリューション
  • ハイブリット手法
    • 平常時はステートフルで
    • SYN Flood攻撃を受けた場合はステートレスに変更する
    • SYNパケットを測定して、規定値を消えたらステートレスに変更
• 結果
  • 現在も稼働中
  • メディアプラットフォームチームはVerdaに移行が完了している

今後の展望

• Managed k8sとの連携
• マルチテナントネットワークへの対応（SRv6のサポート）

LBにとって豊作の時期

• OSS、論文がたくさん公開された
• 今後活かしていきたい

まとめ

ロードバランサーについての最新技術が学べる素晴らしいセッションでした！