- チキンファストフードチェーンのChick-fil-Aは、各レストランでエッジKubernetesクラスタを運用中
- 各店舗のあらゆる機器（フライヤー、グリルなど）がIoTテレメトリ情報を継続的に提供しており、数万台の機器が接続されている
- こうした情報からリアルタイムで需要予測を行い、クラウド側へ送って分析プロセスを実行
- 内部の調理工程からモバイル決済端末（ドライブスルー）まで、すべてが統合されている
Restaurant Edge Compute platform
- 現在の多くのシステムはクラウド/データセンター向けに設計されている
- リソースが限られ、インターネット接続も不安定な環境、そして数千のKubernetesクラスタには適していない
- そこで自前で作ることを決定。MVPを作って実際に導入しながら学び始めた
ハードウェア
- 一般消費者向けのIntel NUCを使うことに決定
- NUCの世代をまとめて3ノードクラスタを構成し、安全性、容量、HA構成まで柔軟に対応
OS
- 最初のリリースではUbuntuをベースOSとして使用
- 設計目標は、単にNUCをレストランへドロップシッピングするだけにすること。レストランごとの手作業設定を不要にするため
- つまり、すべてのプロビジョニングは動的にon-the-flyで動作
- もちろん、いくつかのセキュリティ機能によって、ほかの機器がクラスタに参加したり、内部クラウドサービスへアクセスしたりすることは防いでいる
Edge Commander
- クラスタのブートストラップおよび管理プロセス
- 各エッジクラスタノードは同一イメージで構築
- 複数のディスクパーティションやOverlayFSを使った工夫も含む
- 特定データを長期保持したり、ノードの別パーティションをリモートで削除する"Wipe"機能など
Kubernetes
- K3s実装を使うことに決定
- Kubernetes仕様と互換性がある一方、一部機能を省いており、大規模な設定とサポートが非常に容易
- クラウドを使うわけではないため、Kubernetesの全機能は必要ない
- 非常に満足しており、今後も変更する予定はない
GitOps
- 最初のプラットフォームリリースを構築した時点では、リソース制約のあるエッジで動かせるGitOpsエージェントソリューションがなかった
- 'Vessel'と呼ぶ独自エージェントを開発
- Git Repo（各店舗ごとに固有のRepo）をポーリングし、クラスタ変更を処理
- クラウドのKubernetesクラスタ上でオープンソースのGitLabインスタンスをホスティング中
- 自前でGitサーバーを運用する負担は持ちたくなかったが、コスト効率のよいホスティングソリューションのライセンスモデルを見つけられなかった
Deployments
- GitOpsのために各拠点が自分のGit Repoを指定（Atlasと呼ぶ）
- 各レストランへの新しいデプロイは、Atlasのmasterブランチに新しい設定をマージすることで可能
- このアプローチにはエンタープライズ管理上いくらかのトレードオフがあるが、デプロイ状態の管理と監査を非常に簡単にしてくれた
Supporting a Chain-Wide Deployment
- 最大の挑戦は、MVPから、ごく小さなチームでも維持可能で、しかもスケーラブルでサポート可能なプラットフォームへと変えていくことだった
API First戦略
- ビジネス上の最優先事項は、すべての手動プロセスとバリデーション手順をRestful APIでラップすることだった
- 各手順に対する包括的なAPIスイートを作成し、その上にオーケストレーション層を構築して手動プロセスの自動化を開始
- 包括的でよく文書化されたPostManプロジェクトを作成したことで、新しいAPIを迅速に活用でき、サポートチーム向けWeb UIの作成を後回しにできた
- OAuthを活用してAPIスイートに対するきめ細かな段階別アクセスを提供。特定機能を簡単にロックしたり、顧客向けにnon-invasiveな状態・レポート用エンドポイントを開放したりできた
Dedicated Roll Out Team
- どうやって短期間で大量の機器を各チェーンへ展開できたのか?
- 中核開発チームは非常に小さく、プラットフォームのサポートと開発に加えてチェーン全体へのロールアウトまで支えるのは難しかった
- 全面ロールアウト前に3台のNUCを先に発送して設置しておき、残る作業は設定と検証段階だけにした
- APIスイートが稼働していたため、プラットフォームのリリース、状態監視、簡単なサポート問題の解決を担当する「準技術サポートチーム（semi-technical support team）」を迅速に編成
- Pair-Supportとプレイブック、ドキュメントのフィードバックループを活用して、ロールアウトチームを素早く強化していった
- 数週間でチームは自走可能になり、チェーン全体へのロールアウトを達成
- その後は組織化された構造を通じて、新機能や拡張を進めながらも、プラットフォームに対する優れたサポートを提供できるようにした
- 私たちの目標は、実務的な部分を自動化し、残りのサポート作業をサポートチェーン内で可能な限り上位の段階へ押し上げることだった
- First Tier SupportとSupport DevOpsチームの間のフィードバックループを通じてこれを実現
- すべての問題はファーストティアから始まる
- 解決できない、あるいは新しく複雑な問題が発生した場合はSupport DevOpsチームへ引き渡す
- 両チームが協力して問題を解決し、First Tierチームはドキュメントとプレイブックを更新して、次回同様の問題が起きた際に直接対処できるようにする
- 週次のサポートレトロスペクティブを通じて、DevOpsチームのバックログに改善や自動化の機会を追加
- またSupport DevOpsチームは新規開発チームのバックログにも影響を与え、新しいツールやサポート改善に関する項目から優先順位を決める
Monitoring and Auto-Remediation
- 2500を超えるK3sクラスタがある
- モニタリングプロセスを改善し、クラスタのあらゆる問題を事前に特定して復旧する必要があった。多面的なアプローチを開発
Synthetic Client
- 中核プラットフォーム機能をテストし、問題（サービス問題、データ遅延など）を分析するために、クラスタ内でコンテナとして動作するSynthetic Clientを構築
- 問題が見つかると、クライアントはAPIを通じてCloud Control Planeに報告。サポートチームに通知が送られ、自動化されたRemediationプロセスが開始される
Node Hearbeats
- Kubernetesクラスタには自己修復機能があるため、ノード障害があってもアクティブノード間でワークロードが自動的に再調整される
- ノード障害を検知するため、シンプルな"Heartbeat Pod"をクラスタの各ノードにデプロイ
- このPodは定期的にクラウドのAPIエンドポイントへ状態を報告
Auto Remediation
- 週次のサポートレトロスペクティブを通じて、エラー、検証、修正手順の間にあるパターンを見つけた
- すべてのサポートツールがAPIベースであるため、これらのAPI向けにオーケストレーションフローを構築し、一般的に発生する問題に対して自動修復（Auto Remediation）を行えるようになった
New Capabilities
- インフラの改善を続ける一方で、開発チームはセルフサービス性とサポート容易性を高めるための新しいプラットフォーム機能を継続的に開発した
Deployment Orchestration
- 私たちのGitOpsモデルはシンプル
- 当初は手動変更から始めたが、すぐにクラスタ変更と複数レストランへの展開が可能な"Fleet"というツールを作った
- プラットフォームの成長に伴い、チェーン全体へデプロイし、デプロイの失敗と成功を確認する方法が必要になった
- 第2イテレーションでは新しいDeployment Orchestration APIを開発
- APIとあわせて各クラスタにフィードバックエージェントをデプロイし、デプロイおよび状態情報をクラウドへ報告させた
- これにより、チェーン全体に対するリリースと自己管理可能なカナリアデプロイのパターンを作れるようになった
- こうした変化によって、チームはデプロイを細かく調整して観察できるようになり、デプロイの信頼性が向上した
Log Exfiltration
- 初期には、社内DevOpsチームがレストランのK3sクラスタへ直接アクセスし、リアルタイムで状態を取得してログを検索できるようにしていた
- 基本的なLog Exfiltration機能はあったが、遅延やネットワークの問題のため非常に使いづらかった
- クラスタへのリモートアクセスを最小限にしたかったため、APIエンドポイントを追加し、
- 現在はより強力なLog Exfiltration機能を追加した
- Vectorというオープンソースを活用して、エッジクラスタからログを収集してクラウドへ転送
- フィルタリング、保存と転送、ログの自動ローテーション機能を提供
- クラウド側で別のVectorサービスをセットアップし、すべてのエッジから来るログを収集してルールを適用し、複数のツールへ転送（Data Dog, Grafana, CloudWatchなど）
Metrics and Dashboards
- Prometheus Remote Writeを活用して、すべてのレストランからメトリクスを収集し、クラウドの中央Grafanaへ送る機能を追加
- 各K3sクラスタは、状態、ノード、中核サービスのワークロードをキャプチャする
- カスタムのビジネスメトリクスを公開できる機能も追加した
結論
- 私たちの"Restaurant Compute Platform"とサポートプロセスは、小規模な開発チームでも高い水準の安定性と顧客サポートを提供できるほど十分に成熟した
学んだこと
- 小規模チームがMVPのビジネスクリティカルなEdge Computeプラットフォームを構築するには、優れたエンジニアリングと賢明なトレードオフが必要だった
- 2500を超えるKubernetesクラスタを小規模チームで運用するのは非常に困難だが、API優先の自動化アプローチが大いに役立った
- Cloud-firstの世界から来ると、最大の課題はEdgeには制約があること（計算資源、限られたネットワーク帯域、リモートアクセス）
- 制約条件を把握することに十分な時間を投じ、その制約を取り除くべきか（時間とコストが大きくかかる）、それとも管理すべきかを検討するのがよい
5件のコメント
すごいですね（笑）
本当に基礎の部分から作り上げましたね。適用の過程でも多くのインスピレーションを与えてくれます。
後でもう一度、じっくり通読してみようと思います。
Chick-fil-Aのチキンバーガー、本当においしいですよね（笑）
2018年にもすでに同じテーマの投稿が上がっていましたが、そのときは少し実験的な印象がありました。それが今まで維持されてきたんですね。記事からも、この間にノウハウが蓄積されてきたことがうかがえます。
https://medium.com/@cfatechblog/…
日本には未進出の店舗のため国内での知名度はほとんどありませんが、Piper Sandlerが毎年2回発表している米国の10代による企業好感度調査で、常に飲食店の好感度1位となっている、10代に人気のレストランでもあります。