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