こんにちは、ティアフォーでSREを担当している宇津井です。
2019年9月にSite Reliability Engineering(SRE)として入社して以来行ってきたことをざっと振り返った上で、自動運転の社会実装においてWeb系のエンジニアには何が求められるのかという答えを探っていきたいと思います。スタートアップ企業でどのようにSREの文化を作っていくのかという面でも何かの参考になるのではないかと考え筆を取っています。
と言いつつも重要なことなので最初に書いておきますが、ティアフォーのSREは私が一人目で入社して以来専任としてはずーっと一人でその役割を担ってきました。ようやく一緒に働く方を募集できる状態になりました。そのような背景もあってこのエントリーを書いています。もしご興味がある方は以下のCareersページからご連絡をお待ちしております。
※SRE編とタイトルに書きましたが続編が出てくるかは分かりません。
まず、ティアフォーの場合はオープンソースの自動運転OS「Autoware」を開発する部門とそのAutowareを用いた自動運転エコシステムの導入・運用・開発をサポートするWeb.Auto(MaaS, CI/CD)を開発する部門が存在します。私はWeb.Autoの開発・運用に従事しています。
Web.Autoについてはサービスページ及び昨年行ったミートアップの発表資料をご覧ください。ミートアップ資料では組織・体制・採用している技術スタック等も垣間見えるようになっています。
入社当時の状況
当時のWeb.AutoはFMS「Fleet Management System / 配車管理プラットフォーム」、Maps「地図プラットフォーム」、Drive「遠隔監視・操作プラットフォーム」で構成されており、今考えると自動運転車両を走らせて遠隔監視ができるだけという非常にシンプルな構成でした。ざっくり表現するとパブリッククラウド（主にAWS）上にいくつかのマイクロサービスが展開されていました。
システム構成・アーキテクチャ等についてはAWS Summit 2019 (Tokyo) で発表された資料が参考になります*1。発表されたのは2019年6月の事で私は入社前でしたが、9月に入社したら資料の最後に記載されている今後に向けてというページの内容が全て完了していました。そのスピード感にとても関心したのを今でも覚えています。
また、私が入社した当時は実証実験を日本あるいは世界各地で行いつつもSREは不在で少数の開発部隊で運用・サービス実証を行なっていました。AutowareはStand-Aloneでも走行ができるのでWeb.Autoの主要機能のひとつであるFMS(Fleet Management System)が必要とされない実証実験さえ存在しました。
システム監視だけを切り取って見てもAmazon CloudWatchでいくつかのMetrics Alertが設定されているだけでした。
要はシステムを安定的に動かすとか、高い品質を維持し続ける事、堅牢である事、パフォーマンス、キャパシティプランニング、拡張性といった信頼性に対する取り組みよりも開発スピードが優先されている状況だったということです（組織がシステムの信頼性を重要視していないというわけではなく、何を優先しているかという話です。重要なフェーズに差し掛かったから私がジョインしたわけです）。
SREとして整備した内容
システム把握
そのような中で入社してまず取り掛かったのはAWS Well-Architected Frameworkを参考に「運用の優秀性」、「セキュリティ」、「可用性」、「パフォーマンス効率」、「コスト最適化」の観点について現状どういった状態なのかを自己評価しそこからリスク分析を行いました。自分自身がどの様な状態でシステムが動いているのか知る良い機会になりましたし、上長にどのような順序で何を整備していくのかを説明するのにも客観的な視点が得られて大変役立ちました。
セキュリティ
まず手を付けたのがセキュリティです。弊社は今も昔もAWSをマルチアカウントで運用しています。アカウント数は入社当時で20個ほどあったと思います。スタートアップあるあるですがアクセス権は開発者が皆平等に強めの権限を持っていたりします。流石にrootアカウントは上長のみが保有していましたが、誰かが入社するとそれぞれのAWSアカウントにIAM Userを手作りしているような状況でした（他のAWSリソースは積極的にCloudFormationで作られていたけどなぜかここは手作業で微笑ましかったと記憶しています）。
アクセス権の管理は重要です。 然るべき権限が然るべき人に割り当てられているべきですし、アクセス状況は監査できる必要があります。権限付与も低いコストで行える必要があるし、与えられた権限の利用状況が監査できる必要もあります。別途ICTセクションでSingle Sign-On(SSO)環境を検討していた時期でID Providerが決め打ちできなかったので、AWS OrganizationsをベースにしてIAMロールによるクロスアカウントアクセス環境を構築しました。少し古い資料ですが、2017年のAWS Summitで発表された内容*2に近いものが書かれています。
監査・運用についてはAWS CloudTrail / AWS Config / Amazon GuardDutyがその役割をになっています。
AWS OrganizationsのService Control Policy(SCP)で全AWSアカウント共通の制限（上述のセキュリティ系設定を弄れないようにしたり）も実施しています。
開発者の中に元々セキュリティエンジニアとして活躍されていた方がいたこともあり、互いに協力しあって抱えているセキュリティリスクを洗い出したりもしました。この方はペネトレーションテストも実施していました、専門でやられている方が居たのは心強かったです。
モニタリングとログの統合管理
セキュリティと並行して手を付けたのはモニタリングです。Amazon CloudWatchが悪いわけではないですが、Amazon CloudWatchだけでモニタリング体制を敷くのは結構面倒です。何かのマイクロサービスを追加する度にCloudWatchの設定をチェックして回るのはマンパワー的に無理があります。何かリソースが追加された時でもAuto Discoveryされ、手間なくモニタリングされる世界を作りたかったためDatadogを導入しました。
また、ログ解析にも手間がかかる状態でした。ログは全てAmazon CloudWatch Logsに出力されているまでは良かったのですが、マイクロサービス故にユーザーからは一つのAPIをキックしているだけだったとしても、内部的にマイクロサービスがマイクロサービスを呼び出していたりしてログが分散してしまいます。何か問題が発生した時にこれらのログを見るのにも一苦労でしたし、AWS CLI v2の様にロググループをtailする機能もありませんでした。
そこでDatadogをログの統合管理基盤としても用いることにしました。既にシステムモニタリングとしてDatadogを採用していたこともあり、ツールを新たに増やさす要件を満たしにいった形です。
これで複数のマイクロサービスに跨がる処理もDatadogのFilterを駆使すれば処理の流れをリアルタイムに近い状態で追いかけれる状態になりました。
ここまで出来るとAPM「Application Performance Management / Application Performance Monitoring」やマイクロサービス間の処理をTraceしたくなります。これもDatadogとAWS X-Rayを組み合わせることである程度実現できました。
更には手取り早くE2Eテストを自動化したかったのでDatadogのSynthetics Testも導入しました。E2EテストはDatadogで行うよりもフロントエンドエンジニアがJavaScriptでアプリケーションコードと同じコードベースで記述した方が良いという話が当初からあり、限定的な利用に止まっています。
ブラウザ上で発生したエラーのトラッキングも重要です。いくつか候補が上がりましたが弊社ではSentryを採用しました。これで実証実験の場でエラーが発生したとしても開発者側でトラッキングできる様になりました。
テンプレート・命名規則作り
何のテンプレートだよ、という声が聞こえてきそうですが様々なテンプレートを作成しました。
テンプレートの例としては以下の様な物です。
- AWSリソースのタグ設計
- 利用できるIP Subnet(CIDR)
- 踏み台アカウントの作成方法をCFn化
- AWS Transit Gatewayの作成基準
- 各種Access TokenをAWS Secret Managerから取得する方法
- モニタリングツール導入のコードサンプル
- ログ管理のコードサンプル
- AWSリソースの命名規則
- 技術選定の基準
- etc
一人で全てのマイクロサービスにルールを適用していくのは無理があるので何かルールを決めた際はどこかのサービスへ実装して、他のサービスは基本的にはそのコード化された方法を模倣してもらう作戦で凌いでいます。
将来的にはSREが基盤を作って各マイクロサービスへ自動的に反映される様な仕組みにしていきたいです。
技術選定は大きなトピックなのでこの記事では取り扱いません。
マルチテナンシーへの取り組み
AWSがマルチアカウントで運用されていることは上述しましたが、弊社では実証実験の拠点ごとにAWSアカウントを用意していました。この利点は拠点ごとに異なる要求・仕様に答えやすいし、とある拠点でのデプロイが他の拠点には影響しないという安全性がありました。自動運転業界の特色かもしれませんが、人・物を載せて運行することになるので多少コストがかかっても安全に倒すという傾向があります（ようやく自動運転が出てきた）。
ですが、全国で行われている実証実験は拠点ごとに捉えると1ヶ月のうち毎日行われる物でもありません。拠点ごとにAWSアカウントを作成して各々環境を作っていくとシステムリソースとコストの効率が非常に悪いのです。
大規模に展開していくことを見据えて早いうちに移行した方が良かろうという意思決定をして現在はマルチテナンシーで稼働しています。単純に統合すれば動くというわけでもなく、主に権限管理の仕組みだったりが必要でAWS側の基板だけではなく、APIからWeb画面まで色々な対応が必要でした（これは開発陣が尽力してくれました）。
法律・法令・ガイドライン・基準への準拠
自動運転という領域の特徴の一つとして日本国内だけで考えても道路交通法・道路運送車両法・道路法・道路運送法といった国内法規に準拠する必要があります。法令だけでなく各省庁からガイドラインも発行されます。
また国際規格も目白押しで様々な規格を参照する必要があるのですが、この分野をSREが全て抑えるのは厳しいです。ティアフォーにはSafety Engineerが在籍しているので、彼らから必要とされた物を粛々と対応していくスタイルです（今後はもっと前のめりに対応する必要があります）。
ティアフォーとしては2020年8月に「Tier IV Safety Report 2020」を公開しましたので興味のある方は参照していただければと。
テックブログにも安全への取り組みが連載されていますので合わせて紹介させていただきます。
信頼性に対する取り組み
上記以外にも取り組みは色々ありましたがシステムの稼働状況は大部分が自動計測できている状態になってきたので、いよいよ信頼性自体を定義する運びとなりました。
SLI / SLO / SLA
最終的には高いService Level Agreement(SLA)を定義してお客様に向けてシステムの稼働目標を提示できる様にしたいです。
SLAは近日中に掲げる見込みですが、これに先立って自動運転車両が安全に運行している事を担保するためにもまずはService Level Indicator(SLI) / Service Level Objective(SLO)の設定を行いました。
各マイクロサービスの開発者にヒアリングを行いつつ、開始当初は全社統一の基準を定めてスタートしました。最終プロダクトという状態ではないので自動運転で人命がかかっているとはいえ、99.999%の様なあまりにも高すぎる目標を掲げるのは理にかなっていません。自動運転の安全性は色々な側面で総当たり的に担保しています。この辺りは4半期毎にSLI / SLOの設定内容をレビューし、月毎に結果を取り纏め共有しあっています。
DatadogのSLO機能はリアルタイムでエラーバジェットの残り時間まで表示してくれるので重宝しています。
DevOps文化の醸成
自動運転の実証実験にはアカデミックな側面も見え隠れします。開発者の中には大学からティアフォーに入社して活躍されている方もいます。そうなるとResearch&Developmentはやってきたけど企業でのOperations経験に乏しいみたいな方も在籍しています。
入社して２ヶ月後程度経過した時に「皆んなSREになろう」というサブタイトルでDevOpsとは何か、SLI / SLO / SLAの各指標の説明、モニタリングツールの説明等を行いました。SREを増員する時期ではなかったため開発者を全員巻き込むスタイルを敢行したわけです。
それ以外にも所属する全てのメンバーが共通認識を持つために社内勉強会、会議、実際の業務を通じて、トラブルシューティング、キャパシティプランニング等を行ってきています。
私自身の取り組みではないですがWeb.Autoに閉じず全社一丸となってDevOpsに取り組もうというムーブメントを上長がぶち上げたりもしています。自動運転の走行車両、各地で行われる実証実験までターゲットを拡げているので一筋縄ではいかない面もあると思います。Web.Autoは自動運転システムの導入・運用・開発の全てをサポートするサービスで、DevOpsを推進するサービスという側面を持っているのです。この活動には大きく期待しています。
Incident Management
各地で行われている実証実験ですがその目的は様々です。自動運転業界においては一昨年、昨年まではまだPoCの域に収まった実験が多かったと感じます。ですが、最近ではPoC「Proof of Concept」はある程度こなしてきたから今度はPoB「Proof of Business」だよというシーンが増えてきました。
そうなると自動運転のシステムでクリティカルな問題が発生した場合に組織として対処できる状態が求められます。これまではSlackに飛んできたアラートを緩く心地の良い温度感でSREと開発者が取り扱ってきました。これだとアラートに対してお見合いが発生してしまう事もあります。また、アラートへの対処方法が属人的になってしまったり、そもそもアラートに対応する人に偏りが出てきてしまう側面もあります。
そこでOn-Call、アラート発生後の対応・連絡フロー、ポストモーテムまで一気通貫した管理プロセスを構築しました。
ツールとしてはOpsGenieを導入しました。単位時間を区切ってSREと開発者全員が均等にOn-Callに対処する体制へ移行しています。OSSのグローバル企業という特色を活かし、いずれは24x365のOn-Call体制をFollow the Sunで実現したいと考えています。夜中の対応とかきついですからね。
まとめ
OSSによって「自動運転の民主化」実現を目論むスタートアップにSREが入社してSREとして整備してきた事を振り返ってみました。スタートアップでは個人の業務範囲が広くなりがちなので、それこそエンジニアの仕事ではない様な事も取り組んだ気がします。ここに書いた事以外の事にも多くの時間を使ってきたと思いますがそれはそれで楽しい時間でした。
SREとして信頼性を武器に自動運転の社会実装を行いたいという方がいれば是非ともそのお力をお貸しください。業界自体が謎めいていると思うのでMeetup等を活用していただけると幸いです。
直近では1/29(金)19:00より「Tier IV 自動運転Web&Dataミートアップ」というタイトルで開催予定です！
