自動運転を支えるWeb技術 - 信頼性への取り組み (SRE編)

こんにちは、ティアフォーでSREを担当している宇津井です。

2019年9月にSite Reliability Engineering(SRE)として入社して以来行ってきたことをざっと振り返った上で、自動運転の社会実装においてWeb系のエンジニアには何が求められるのかという答えを探っていきたいと思います。スタートアップ企業でどのようにSREの文化を作っていくのかという面でも何かの参考になるのではないかと考え筆を取っています。

と言いつつも重要なことなので最初に書いておきますが、ティアフォーのSREは私が一人目で入社して以来専任としてはずーっと一人でその役割を担ってきました。ようやく一緒に働く方を募集できる状態になりました。そのような背景もあってこのエントリーを書いています。もしご興味がある方は以下のCareersページからご連絡をお待ちしております。

tier4.jp

※SRE編とタイトルに書きましたが続編が出てくるかは分かりません。

まず、ティアフォーの場合はオープンソースの自動運転OS「Autoware」を開発する部門とそのAutowareを用いた自動運転エコシステムの導入・運用・開発をサポートするWeb.Auto(MaaS, CI/CD)を開発する部門が存在します。私はWeb.Autoの開発・運用に従事しています。

Web.Autoについてはサービスページ及び昨年行ったミートアップの発表資料をご覧ください。ミートアップ資料では組織・体制・採用している技術スタック等も垣間見えるようになっています。

web.auto

Tier Ⅳ Tech Meetup #2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 - from Tier_IV

www.slideshare.net

入社当時の状況

当時の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)が必要とされない実証実験さえ存在しました。

実証実験の風景 〜 某キャラクターに似ているというmilee

システム監視だけを切り取って見ても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」を公開しましたので興味のある方は参照していただければと。

tier4.jp

テックブログにも安全への取り組みが連載されていますので合わせて紹介させていただきます。

tech.tier4.jp

tech.tier4.jp

信頼性に対する取り組み

上記以外にも取り組みは色々ありましたがシステムの稼働状況は大部分が自動計測できている状態になってきたので、いよいよ信頼性自体を定義する運びとなりました。

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ミートアップ」というタイトルで開催予定です！

tier4.connpass.com

*1:https://pages.awscloud.com/rs/112-TZM-766/images/K3-03.pdf

*2:https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T2-2.pdf

自動運転システムの性能限界検知と環境センシングに関する取組み

こんにちは、ティアフォーで自動運転システムを開発している川端です。
今回はシステムの性能限界検知と環境センシングに関する取り組みの一部をご紹介します。

１、自動運転レベルとODDによる走行条件定義

【自動運転レベル】

自動運転のレベルはSAEの定義に沿う形で０から５までの６段階に分けられることが主流となっています*1。そのうち、レベル３以上の定義は以下のようになっています。

レベル３（条件付運転自動化）

運転自動化システムが全ての動的運転タスクを限定領域において持続的に実行。この際、作動継続が困難な場合への応答準備ができている利用者は、他の車両のシステムにおける動的運転タスクの実行システムに関連するシステム故障だけでなく、自動運転システムが出した介入の要求を受け容れ、適切に応答することが期待される

レベル４（高度運転自動化）

運転自動化システムが全ての動的運転タスク及び作動継続が困難な場合への応答を限定領域において持続的に実行。作動継続が困難な場合、利用者が介入の要求に応答することは期待されない

レベル５（完全運転自動化）

運転自動化システムが全ての動的運転タスク及び作動継続が困難な場合への応答を持続的かつ無制限に（すなわち、限定領域内ではない）実行。作動継続が困難な場合、利用者が介入の要求に応答することは期待されない

すなわち、レベル４以上の自動運転の実現には、作動継続が困難な場合でも利用者による介入を求めず、自動運転システムが周囲環境やシステムの状態を検知し安全に運行停止措置へ移行する、等の応答が求められます。

では「作動継続が困難な場合」とはどのような場合でしょうか？ここでODDという概念が登場します。

【ODDによる走行条件定義】

ODD*2とは、自動運転システムが作動する前提となる走行環境条件のことで、以下のようにいくつかのカテゴリに分けて考えることができます（参考：Tier IV Safety Report 2020、自動運転LAB）

1. 道路条件：高速/一般道路、車線数、車線や歩道の有無など走行する道路に関わる条件
2. 地理条件：都市部/山間部/ジオフェンス内など周辺環境も含んで設定する条件
3. 環境条件：天候/日照/昼夜/温度など環境に関わる条件
4. その他：速度制限/インフラ協調の有無/オペレータの乗車要否/連続運行時間などの運行に関わる１〜３以外の条件 

ODDは全ての条件を満たす場合に自動運転システムが正常に作動するように定義されます。例として、先日国土交通省からリリースされた自動運転車（レベル３）に関する発表資料の主な走行環境条件で以下のような記載がありました。

環境条件（気象状況）

強い雨や降雪による悪天候、視界が著しく悪い濃霧又は日差しの強い日の逆光等により自動運行装置が周辺の車両や走路を認識できない状況でないこと

すなわち、上で登場した「作動継続が困難な場合」とは「走行環境が事前に定義されたODDの条件を満たさなくなった場合」と解釈することができます。このようにODDを事前に定義し、その条件の中でシステムを作動させることで、走行時の安全性を担保することが可能となります。

一方で、ODDの極端な例として「悪天候（雨、雪）や霧、逆光を含まない明るい環境」と定義することもできますが、そのような場合には少しでも雨が降ったり、日が傾いて逆光になると（走行条件から外れて）システムが作動できなくなり、自動運転による本来のメリットを得ることが難しくなってしまいます。そのため自動運転システムの設計には、安全性を確保しつつ、同時にシステムの可用性(Availability)も高めていくことが求められています。

以上を簡単にまとめますと、レベル４以上の自動運転を多くの環境で使えるものとしていくためには、システムに対して、

• 時々刻々と変化する走行環境に対してODD条件の評価を行い、外れた場合には縮退運転やMRM*3などの応答を安全に実施できること
  
• 雨、霧、逆光などを含む様々な走行環境で安全に走行できること

といった要素が求められます。

２、悪天候環境下で生じる課題と環境センシング 

日々の実証実験の中で様々な環境や気象条件に遭遇し課題が発生します。
特に日本の平均年間降水量は世界平均の約２倍と言われており、雨や霧に関連した課題に遭遇するケースが少なくありません。

例として、図１は急な降雨による気温低下と湿度上昇によってカメラのレンズ付近に水滴（結露）が付着し、光が回折することでカメラの画像にゴーストが生じている例です。

図１：水滴（結露）により生じたゴースト

図２はLiDARが発する赤外線が空気中の水滴によって反射されることで、あたかも障害物が存在するように見えている例です。

図２：空気中の水滴により生じたゴースト（点群の色は地面からの高さに相当）

これらの課題は日中の晴れた環境において生じることはほとんど無く、自然の環境変化によって偶発的に生じるため、対策の効果や再現性の確認、また体系的な評価を行うことが難しい領域となっています。

そのような状況を解決するための一つのアプローチとして、防災科学技術研究所（茨城県つくば市）との共同研究を通して、制御された悪天候環境下での技術開発を進めています。 

本共同研究では図３に示すような車両を用いて、降雨強度、視程、照度といった環境パラメタのセンシング技術の開発と、環境パラメタとシステム性能の関係のモデル化にトライしています。 

図３：R&D車両（通常の自動走行用のセンサに加えて、環境センシング用に照度計やディスドロメータ、降雨強度計などを搭載）

３、防災科学技術研究所との共同研究における実験内容の紹介 

防災科学技術研究所の大型降雨実験施設は、天井に配置された直径の異なる４種類のノズルからの流量を個別に制御することで、雨粒の分布を制御しながら、降雨強度15(mm/h)から最大約300(mm/h)までの範囲 *4 で人工的に雨を降らせたり、霧を発生させることができます。また、地面からノズルまで約20(m)の高さがあるため、ノズルから吐出された水滴が落下に伴って拡散し、局在の少ないより自然の雨に近い環境を再現できるように設計されています。図４に降雨実験の様子を示しました。

図４：降雨実験の様子（細かい雨粒で降雨強度50mm/hを再現）

図５に降雨強度を変更しながら取得したLiDAR点群（最上段、上面図）とカメラ画像の例を示します。今回実験に用いたLiDARは波長903nmの赤外線を周囲に向けて発し、物体からの反射光の位置と強度の情報をマッピングすることで３次元の情報を得ています。今回の例では降雨強度の値が大きい50(mm/h)よりも、細かい雨粒をより多く発生させた30(mm/h)の方がLiDARでの周囲認識の性能やカメラの視界が悪化する傾向が定性的に確認できました。また、図３に示した車両に搭載された計測機器で雨粒の落下速度や大きさの分布等も計測することができているため、上記の傾向を定量的に把握してモデル化するためのデータを蓄積することができています。

図５：降雨強度によるLiDAR点群分布・カメラ画像の変化（点群の色は反射光強度に対応）

４、LiDAR点群による降雨強度推定

環境センシングの応用例として、自動運転車両で一般に使用されているLiDARの点群情報を用いて降雨強度を推定するモデルの開発事例を紹介します。雨粒の大きさや分布と赤外線の吸収や散乱強度の間には相関があることが知られており（参考文献１）、その相関を利用してBayesianモデリングの手法（参考文献２）に基づいてLiDAR点群（雨粒や周囲物体からの反射光の強度分布）と実測した降雨強度との関係をあらわす確率モデルを開発しています。Bayesianベースのモデルを用いることで推論結果の不確かさも同時に見積もることができるようになっています。 

図６：開発中のモデルによる推論結果の例（プロットの色は真値が予め定めた±5%のエラー範囲の外に存在する可能性の大きさを示しています）

このように、制御された悪天候環境での系統的な評価やデータ収集を行うことで、自動運転で一般的に利用されているセンサを用いて環境パラメタの推定が行える例を示しました。このようにして得られる情報を用いて、自動運転システムを安全に運行させるために必須となる自己位置推定や物体認識といった機能の性能との対応を確認しながら、システム性能のモデル化を進めております。

今後は降雨強度だけでなく視程（MOR）、環境照度、路面の摩擦係数などODDを定義する上で重要な様々な環境パラメタに関して研究開発を進めていきます。 

５、まとめ

以上、性能限界検知に関する環境センシングの開発事例をご説明させて頂きました。
ここまでで述べましたように、自動運転の技術開発はソフトウェアに関する部分だけではなく、自然現象に関するセンシング技術や物理解析といった分野でも多くの知見が必要となりますし、不確かさを定量的に扱うための数理的な素養なども必要になります（確率的な推論モデルの構築に関してはティアフォーのリサーチャーと共同で実施しています）。ロボットやソフトウェア開発がご専門でない方でも、我々と一緒に新しい技術開発にチャレンジしたいというパッションをお持ちの方は下のリンクより是非ご連絡頂ければ幸いです。カジュアル面談も随時受け付けております。

tier4.jp

６．謝辞

この報告は、国立研究開発法人防災科学技術研究所との共同研究「悪天候環境における自立移動体の外界センシング性能の検証および向上等に関する研究」（令和２年度）の成果の一部です。特に、酒井直樹主任研究員、小林政美専門員には、降雨や実験に関する多くのご知見を共有頂きました。この場をお借りして深く感謝致します。 

以上

（参考文献）

1: A First course in Atmospheric Radiation, Grant W.Petty, Sundog Publishing,p.346-, 2006

2: Pattern recognition and machine learning, Christpher M. Bishop, Springer, 2006

*1:日本では公益社団法人 自動車技術会発行の資料において日本語で定義されています。

*2:Operational design domain、運行設計領域

*3:Minimal Risk Maneuver

*4:300(mm/h)は日本の過去のゲリラ豪雨でも最も強いクラスに相当

Unity for Industryでお話した事と紹介しきれなかった事

皆さんこんにちは、ティアフォーでSimulationチームに所属している織田です。

先日、「Unity for Industry」と言うウェビナーで、人生初の大勢の前(?)で話す実績を解除しました。

今回のTech Blogでは、その際にお話した事と紹介しきれなかった部分を書こうかと思います。

Unityだから出来た自動運転車両の設計を加速させた話

Unity for Industryではこのタイトルでお話をしました。

お話をかいつまみますと

• 自動運転で使用するセンサの構成の検証が大変。
• 検証が可能な場所の用意や、取れるデータを推測しながら構成しなければならなかった。
• 上記の点を調整して、目的のデータが取れなければ再度構成の見直しを行う。
• Unity/LGSVL-Simulatorを使用すれば、場所もデータ取りもシミュレーション可能になる。
• 作ってみた。Unityだったので割と早めに実現できた。
• センサ構成を検討する際に、このシミュレータを使用する事で事前に構成の検証が出来る様になった。
• 良かったね。

上の様なお話をいたしました。

ウェビナーで紹介しきれなかった部分

下記の様な環境をシミュレーターで検証しました。

10m/30m/50m/100m先に人が立っていている場合、LiDARはどの様に人が立っているのを検知出来るか?

100m先まで人がいる状態

100m先まで人が並んでます

この時の50m地点の人のLiDARの当たり具合

50m先だと2lineくらい当たってますね

同様に、この時の30m地点の人々

30m先では6lineくらい当たってますね

やはり100m先を見通せる広くて平らな環境と言うのは現実環境ではすぐに用意できないのでこの環境の様な検証はシミュレーターが向いていますね。

30m先の人々と50m先の人々を比較してみると、50m先の人々の方がLiDARのスキャンの間隔が開いてしまい、検知可能な点が少なくなってしまう事が判別できます。

10%の勾配で30〜35m先の坂の上に立っている人はLiDARでどの様に検知されるか?

10%勾配で30〜34mに人々が立っています

30〜34m付近にいる人々

30mから1m毎、34mまで並んで立っています

こちらのケースも、実世界では10%勾配に見事にマッチする環境を探すのは難しいですが、シミュレーターでは勾配を変更した場合のケースも値を変更することですぐに用意できます。

30〜34m先の人々には勾配の先にいると言う事もあってか、先の平地での30m先の人に比べると全くと言って良い程LiDARのスキャンが届かない様に見えます。

LiDARを車両のどの位置に、どの様な角度で設置するとどの範囲を測定できるのか?

計測範囲を可視化した図

ここでは、追加で作成したLiDARが測位する範囲を可視化させた物を設定する事で測定範囲を可視化しています。緑、黄、青の範囲の外側だと、車両が停止している場合に計測できない領域となる箇所が一目瞭然ですね。

課題

ゲームエンジン/センサシミュレーションでもまだ解決出来ない問題はあるのです。

悪天候

雨/霧等、ゲームエンジンでは画面上のビジュアルに向けた実装は多いですが、センサで取れるデータと言うものに関しての考慮はやはりされていないので、どの様に実装するのかは現状の課題になっています。

とは言え、何も手が無い訳ではなくて例えばUber Advanced Technology GroupがLiDARsimと言う形で、現実的なセンサのデータに近付けるといった研究をされていたりします*1。

こちらを応用したりすれば、解決していける課題になっていくのではないかと今は考えてます。

データを効率良く捌く

センサシミュレーションで取るデータは現状

• LiDARによる点群計測

が主なのですが、計測する為の点群のデータ量はかなり膨大で、且つ高頻度で効率良く処理する方法も課題となっています。

まとめ

現実では用意が難しい環境でもシミュレータによって検証出来るようになり、事前にどの様なデータが取れそうか？等が容易に検証できる様になりました。

この辺はゲームエンジンの面目躍如です。

又、新たなセンサの構成を検証する際にもリアルタイム且つ柔軟にセンサの確認が出来るのもゲームエンジンだから可能になったと言えるでしょう。

ティアフォーでは、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければと思います。

tier4.jp

又、2020年1月29日（金）の夕方にはTech Meetupを開催する予定ですので、もしお時間が合う方はご参加下さい。

tier4.connpass.com

*1:https://arxiv.org/pdf/2006.09348.pdf

ROS2 rmwを切り替えてpub/sub通信しよう

こんにちは、ティアフォーエンジニアの村上です。今回は、ROS 2の通信機能に関するお話をしたいと思います。

自動運転OSSの「Autoware」は、ROS 2の上に構築されており*1、ROS 2はその通信 (出版/購読) backendとしてDDS (Data Distribution Service) を採用しています。多くのプロセスからなるAutowareにおいて、通信は注目すべき要素です。安心・安全な自動運転の実現のためには、Autowareの機能自体はもちろんのこと、通信のようなbackendについて、各systemに対するtuningをすることは不可欠です。 今回はそのROS 2/DDSについて調査した時のreportです。

ROS 2のProtocol Stack

従来のROS (便宜上ROS 1と呼称します) においては、独自の出版/購読の仕組みを実装していましたが、ROS 2ではDDSのAPI等をinterfaceとして、具体的な出版/購読の実装をROS本体から分離しました。このlayerこそがrmw (ROS MiddleWare)です。我々は各DDS実装に対するrmwを使用することで、application側でコードを変更することなく、各DDS実装を切り替えて使用することができます。

下記の図は、ROS 2の、特に通信に着目したProtocol Stackです。

backendは様々なものを考えることが可能で、layerというものではありません。例えばPOSIXで提供されているある種のprocess間通信、RTPSのような通信protocol、RTOS (Realtime OS) でサポートされている特殊な通信API、直接Network-on-Chipなどのhardwareを扱うなんてことも考えられるでしょう。
このように、rmwやrclcによって、個別の実装は隠蔽されており、各backendに適したrmwを使いわけることで、tuningを行うことができます。

ここまでの用語を整理しておきましょう。

RMW (ROS Middleware)

各DDS実装あるいは各backendの差を吸収、あるいは最適化を施している層。rclcに対して共通のinterfaceを提供する。

DDS (Data Distribution Service)

publish/subscribe programmingを実現するAPIを規定する。同じ立ち位置のAPIとしては、例えばSocketやMPIがある。

RTPS (Real Time Publish-Subscribe)

transport-layerよりも上層に位置する通信protocolの一つ。同じ立ち位置の仲間としてはHTTPなど。protocolの位置関係は、DDS API over [RTPS/UDP/IP/Ethernet]のようになる。

共有メモリを使用するrmw

Autowareの通信を考えるとき、いかにも最適化できそうなものとして、例えば以下のような特徴があります。

• 高性能sensor群からの大きなdataの通信が存在するが、出版者と購読者が1対1で、dataを出版後に参照することはない
• GPGPUを活用している認識以外の大部分の処理は、1 hostで処理されている計算機systemである

帯域量を求めるROS node間通信と応答時間を求めるROS node間通信は、Autowareにおいて混在していますが、今回は後者の応答時間を考えたいと思います。

応答時間に対するROS 1での最適化については、nodeletを積極的に使用していました。
nodeletは1 processの中で複数のnodeを実行する仕組みであり、その通信はpointer passing、所謂参照渡しとして実装できます。ROS 2においてもこの仕組みはexecutorという、より発展した形として提供されておりますが、これらが共通して抱えている課題点はapplication levelでの変更が必要な点です。nodeletを使用しない場合、ROS 1では、たとえ1 hostの計算機で閉じていようが、socket API over [TCP or UDP]経由の通信しかできません。

対してROS 2では、先に触れたrmwより下層の切り替えのみで最適化を行うことができ、applicationへの変更は一切必要ありません。

それでは実際に、今回の条件に適しているであろう、rmw_iceoryxを使用してみたいと思います。iceoryxはshared memory上でのdata転送を効率よく行う仕組みを提供しており、今回のようなlocalhost上限定の状況では、よい選択肢となります。このような転送はiceoryxの専売特許というわけではありませんので、実際にrmwの選定を行うときには、より広い選択肢があるでしょう。
(するどい方は、DDSのAPI等と濁したことに気がついているかもしれませんが、iceoryxはDDSのAPIを提供しているわけではありません。今回はrmwをI/Fとしますので、DDSに類する機能を内包さえしてしまえば、stackは厳密に積まれる必要はないのです。)

rmw_iceoryxの応答時間評価

rmw_iceoryxのbuild

環境は、Ubuntu 18.04 ROS 2 Eloquentです。
rmw_iceoryxはgithubからcloseしてきてください。

基本的には、rwm_icoryxのreadmeのInstallationを参考にしますが、最後のcolcon buildにおいて、下記2点に注意してください。

• sys/acl.hがない場合; apt install libacl1-dev
• rosidl_runtime_cのcmake用のconfigがない場合; rmw_iceoryxがmaster(foxy用)かもしれません。eloquent用のbranchに切り替えてください。

  cd src/rmw_iceoryx; git checkout -b eloquent origin/eloquent

サンプルプログラム

今回使用するpub/sub サンプルプログラムは、2MB/100msのtopicをpublish/subscribeさせ、その間のlatencyを出力するprogramです。この2MB/100msの数字は、高性能なsensor一つの出力を模しています。

実行

1. まず、shared memory及びその上のpub/subを監督する処理を立ち上げます。
   

   ./iceoryx_ws/install/iceoryx_posh/bin/iox-roudi

2. 次に、以下のようにRMW_IMPLEMENTATIONを指定して、sample programを起動します。
   

   source /opt/ros/eloquent/setup.bash
   source iceoryx_ws/install/setup.bash
   source pubsub/install/setup.bash
   RMW_IMPLEMENTATION=rmw_iceoryx_cpp ros2 launch comm inter_process_pubsub.launch.py

環境変数RMW_IMPLEMENTATIONを特に設定しなければ、default(fastrtps)による通信が行われます。また、latencyの出力については、launcherの設定で~/.ros/log/[日時]/launch.log以下に出すようにしています。

動作比較

応答速度としては、Fast RTPS > Ice Oryx > executorが予想されます。それぞれ応答速度と引き換えに制限が発生します。それは1 hostの制限であったり、単一障害点の発生であったり、published dataを参照するnode数 etc…であったりです。 また、使用したrmwはそれぞれdefaultの設定を使用しており、tuningの余地は十分にあります。

Fast RTPS (Default DDS)

上述の通り、何も設定しない状態でのpubl/subです。

Process内 (executor)

rmw層下の話からは逸れる話ですが、先に触れたprocess内のpubsubでは、実装やコーディング制限が伴う可能性はあるものの、それに見あうだけの非常に高速な応答性があります。今回はsingle thread executorを使用しました。起動方法としてはros2 launch comm intra_process_pubsub.launch.pyで起動できます。

Ice Oryx (固定長message)

Ice Oryx (可変長messega)

上述のサンプルプログラムのvariable_messageブランチで計測ができます。固定長との違いは、message typeでstd_msgs/ByteMultiArrayを指定している点です。

最後に

今回は実験として、rmwを切り替えた時の応答速度の変化を見てみました。話を簡単にするため、Autowareではなくsample programの上で観測しましたが、Autowareにおいても十分期待ができる結果です。また、rmwの切り替えだけという、非常に簡単な方法でtuningができるということも実感できました。ただし、観測結果については通信以外の部分の考慮をしていないため、厳密な評価ではないでしょう。それでも、大雑把にこれだけの差が出ることは、大変に興味深い結果です。

ティアフォーでは、今回ご紹介したように、自動運転ソフトウェアの開発だけでなく、自動運転という最先端のApplicationに対するECU/Middlewareの設計開発も行っており、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです。

tier4.jp

補遺、参照

1. ROS on DDS (ROS本家tech. blog)
2. ECU; 車載向けのcontroller(計算機)の意味。完全自動運転が要求するspecは、通常の車載system、自動運転支援systemと比べても幾分か高い。性能及び組み込み的な安全性を考慮する点は、非常に挑戦的である
3. rmw-[implementationの名前]; 各DDS/RTPSに対するrmw側実装。github上に存在はしても、Full Supportか否かは別途確認が必要がある点に注意
4. ゼロコピー転送; 通信時にコピーが発生しない転送。process間のshared memory上を介した実装がIce-Oryx。process内のpointer passingによる転送もゼロコピー転送。転送先のみがそのデータを使用する場合に有効で、応答速度やメモリ消費量が改善する。そうでない一般の通信はコピーが必要だが、大きいデータを扱う時は注意が必要。以下の例では700MBほどの地図データが何重にもコピーされてしまっている
   

*1:Autoware.AIはROSで動くように設計されていたがAutoware.AutoはROS 2上で動くように設計されている

Web.Auto 全体チーム社内開発レビュー会を開催しました

こんにちは、ティアフォーでWebサービス開発を行っている桑原です。

今回はティアフォーが開発をリードしている自動運転ソフトウェア「Autoware」の開発・実証実験を支え、自動運転サービスのために必要なWebの基盤を開発しているチームの活動と開発しているWebアプリケーションの概要を紹介します。

Web.Auto 全体チーム開発レビュー会

ティアフォーが開発しているWeb.Autoは、IoT・Cloud技術を用いて、様々な組織・個人が迅速かつ簡単に自動運転テクノロジーにアクセス可能となり、自動運転サービスに関する幅広い課題を解決できる基盤となることを目指しているサービスです。自動運転サービスを導入・運用するための多くのWebアプリケーションを開発しています。

今回 Web.Autoチームではこれらのサービスが顧客に届ける価値をより高めるために、自動運転ソフトウェアの開発から実際に自動運転サービスが届けられるまでのWebアプリケーションの利用例をユーザーストーリーとして作成して、各アプリケーションが実際に使われるイメージ全体を共有するチーム横断の開発レビュー会を行いました。

この会の目的としては以下の通りです。 

• チームで閉じた開発であったり、機能ベースの開発ではなく、どのようなものが顧客に取って価値になるか考え、プロダクトを市場に届けるところまで考えれるようになる
• 自分の担当するシステムやチームの中での部分最適な開発ではなく、横断的な開発ができるようになる

自動運転技術においては専門的な知識が多く、Webアプリケーションの開発でも多角的な観点から開発するのが難しくなってしまうので、この会を通して目指しているビジョンを再認識して、開発が促進できるように開催されました。

Web.Auto サービスの全体ユーザーストーリー

実際に自動運転のサービスを提供する場合、大きく分けて以下のフローを踏んで自動走行が可能であることを確認します。実際にはもっと多くの細かい手順がありますが、ここではWebアプリケーションで補助できる部分に限った大まかなユーザーストーリーとなっています。

1. 自動運転ソフトウェアの開発とテスト
2. 自動運転サービスのための事前準備
3. 実車試験
4. 自動運転サービスの運用と監視
5. 自動運転の走行分析

次に各手順に沿ってストーリーの詳細を紹介します。

1. 自動運転ソフトウェアの開発とテスト － Testbed & CI/CD Pipeline

自動運転ソフトウェア「Autoware」の開発・評価を、安全を担保しながら信頼性高くかつ効率的に行えるようにするための開発者向けのテスト評価フローです。

自動運転ソフトウェアの開発者が機能の改良を加え、テストを実行・評価して、実車テストまで行う作業の障壁を軽減するためのユーザーストーリーです。このセッションのレビュー会の内容は以下になります。

• 自動運転車に取り付けるセンサーのシミュレーション
• 自動運転ソフトウェア「Autoware」のシミュレーションテスト

1. 車両の構成などをまとめたファイルの作成
2. テストの要件からテストシナリオを作成
3. テストの実行
4. テスト結果の確認・リプレイ
5. Web.Auto基盤から接続車両に配信可能状態なパッケージを生成

シミュレーションのリプレイ画像

Webアプリケーションでこれらを確認することで、早く安全に実車テストを行うことを可能にします。

より詳細な内容は以下の記事で紹介しています。

tech.tier4.jp

2. 自動運転サービスのための事前準備 － Setup for Self-driving Services 

自動運転車サービスには配車管理コンソールへの車両の登録と接続の設定、自動運転ソフトウェアや車両アプリケーションのインストール、地図の設定が必要です。ユーザーストーリーとしては自動運転車サービスを運用する管理者のサービスの準備となります。このセッションのレビュー会の内容は以下の通りです。

• 配車管理コンソールでプロジェクトと走行環境の設定
• 車両と配車管理コンソールが接続できるように車両の証明書を発行し、車両に設定
• 自動運転車両で使用する地図を地図ツールから配車管理コンソールにアップロード
• 配車管理コンソールから車両へ「1. 自動運転ソフトウェアの開発とテスト － Testbed & CI/CD Pipeline」の手順で生成したパッケージを配信

地図ツール画面

これらのIoT・Cloud技術で車両の管理やサービスを扱う準備を一層簡単にすることで、自動運転サービスをより早くまた安全性高く提供することができます。

3. 実車試験 － Operation for Self-driving Vehicles

自動運転車の現地試験運用を迅速かつ安全に行えることを目指した、車両オペレーターによる開発車両運用中のフローです。現在は自動運転車の車両が安全に運行できるように車両オペレーターが実際に自動運転車両が正常に動いているかどうかを監視しているので、ここでは車両オペレータが監視して実車の走行をテストするユーザーストーリーになります。

ティアフォーが行っている実証実験では、実際にオペレーターが以下の走行を監視しています。

基準緩和申請を行えば時速20キロまでなら運転席無人の自動運転タクシーを運行できるようになりました。次回は時速30キロ、複数台、広域エリアでの運行を目指します。 pic.twitter.com/1myurA3tBq

— Shinpei Kato (加藤真平) (@ShinpeiKato) November 6, 2020

オペレーターが自動運転の状態監視を行えることで安全に実車のテスト走行を実行することが可能になっています。

4. 自動運転サービスの運用と監視 － Management for Self-driving Services

自動運転車サービスの運用を迅速に、安全に、簡単に行えるようにする運用管理者・遠隔監視者・車両オペレーター・サービスユーザー向けのサービス運用中のフローです。自動運転の運行事業者が自動運転車両のサービスを提供するエリアに関して、走行の環境や地図を更新して、自動運転車両の配車サービスを運用するというユーザーストーリーになります。今回のレビュー会では実車ではなく、自動運転の走行を模擬するシミュレータを使って仮想的にサービスを確認しました。

• 運行管理コンソールから自動運転車両を配車リクエスト
• 車載タブレットから出発ボタンを押して走行
• 運行管理コンソールから自動運転の走行の状態を確認
• 運行管理コンソールから車両のカメラ映像を確認

運行管理コンソール画面

車載タブレット画面

運行管理に関しては以下の記事で紹介しています。

tech.tier4.jp

遠隔監視・運転システム画面（※画面ははめ込みです）

また遠隔からの操縦に関する取り組みは以下の記事で紹介しています。

tech.tier4.jp

5. 自動運転の走行分析 － Inspection for Self-driving Services 

自動運転車サービスの運用や開発のフィードバックのための運用管理者・開発者向けのサービス監視・評価のフローです。運行事業者や自動運転ソフトウェアの開発者が蓄積された走行データを分析して、サービス運用および開発のフィードバックを行うことができるようになります。また、実際に走行したプローブデータを収集して蓄積し、分析しやすい形で走行ごとに車両の状態を振り返ることができます。運用管理者が走行テストや自動運転サービスが終了したのちに自動走行の安全性の分析をするユーザーストーリーなります。

走行履歴画面

まとめ

Web.Auto チームでは以上の他にも様々なシステムとアプリケーションを開発しています。今回は半日かけて自動運転のサービスを提供するまでのユーザーストーリーについてレビュー会を開催しました。本レビュー会は、テックカンファレンスのようにそれぞれのアプリケーションの担当が開発背景やシステムの概要を発表し、実際動くデモを発表する形で進めました。

このレビュー会を通して、自分が担当するシステム以外の開発がどのようにユーザーまでつながっているかを一貫して全Web.Autoチームで見ることでより良い改善を進めることができています。いずれは勉強会やテックカンファレンスなどで「自動運転の民主化」に向かって、今回説明したものよりさらに改善が進んだアプリケーション・システムを紹介していきたいと思います。

ティアフォーでは、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければと思います。

tier4.jp

安全への取り組み：②自動運転の安心・安全について

こんにちは、ティアフォーのSafety Engineerの須永です。

ティアフォーの安全への取り組みを数回に渡って紹介していくシリーズの今回は第２回目になります。第１回目については以下をご参照下さい。

tech.tier4.jp

最近、社内では機能開発に向けた実車機能テストが増えてきています。公道での実験もあることから、より一層、安全意識を持った実験を行う必要が出てきています。そこでティアフォーでは安全に関する社内の勉強会を隔週で開き、社内における安全意識と知識の醸成を図っています。

そのような取り組みの中で今一度初心に帰り、「安心・安全って何だろう？」ということの確認と自動運転の安全を確保していくための私達のアプローチを確認しました。今回の記事では、その内容をお伝えしようと思います。

そもそも安心・安全ってなに？

ティアフォーの中でも安心・安全の議論はよくされます。しかし人によって言葉の解釈が異なるので、話がかみ合っていないことが多々見られました。似たような言葉に信頼や品質という言葉もあります。この違いって何でしょう？

いろいろな観点があるのでこれが絶対的な正解だとは言うことは難しいですが、まずは安心、安全、信頼の言葉の意味を社内で定義してみました。

　安心

• 主観的心理過程であり、定性的、相対的
• 人の思い込み
• 気にかかることがなく心が落ち着いていること

　安全

• 科学的根拠があり、定量的、客観的、絶対値比較
• 人に危害を加えない
• 危害または損傷・損害を受けるおそれのないこと

　信頼

• 科学的根拠があり、定量的、客観的、絶対値比較
• 与えられた機能を続ける
• 対象を高く評価し、任せられるという気持ちを抱く意を表す

安心なものは安全なのか？

安心とは、漢字の示す通り人の心が関与していて、不安を感じていなければそれは安心していると言えます。 つまり、安全でないものでも不安を感じなければ安心していると言えます。

安全なものは安心なのか？

安全とは、人やものに危害が加わるかどうかの確率です。危害が加わる確率が非常に低くくとも、その人にとって過去の経験から不安であったことを思い出させるようなことがあれば、それは安心しているとは言えなくなります。つまり、安全なものでも安心しているとは言えないものもあると言えます。

安心はどのように生まれるのか？

安心の反対である不安を人はどんな時に感じるかというと、期待を裏切られた時や悪い経験が惹起される時などに感じるもので、つまり現在あるいは過去に信頼を裏切られた結果として不安を感じるのだと思います。つまり、安心を得るためには信頼を裏切らない、信頼を回復して任せてもらえる状態にする、心を許してもらえる状態にすることが必要になってくると言えます。

安心・安全の関係性

安心≠安全だとすると、安心・安全の関係性について考えてみる必要が出てきます。

まず、何にせよ人が使う物に関して安全は必ず必要になります。その上でどう安心を提供するのかというと、その間に信頼が必要になってきます。ティアフォーでは、安全の上に信頼があって初めて安心が芽生えていくものだと考えました。 

安心・安全・信頼の関係性

安心・信頼を得るために

これらを整理した上で、自動運転について安全を確保した上でさらに必要な安心を得るためには、信頼を得ることが必要であるとしました。信頼を得るためのアプローチとして、

• 沢山走っても事故が起きないことを示し信頼を得ること
• 実際に体験してもらい期待を裏切らないこと

が重要だと考え、ティアフォーでは信頼とその先の安心を得ていくために、自動運転を安心だと感じてもらうべく、また実際に体験してもらうべく日本各地での実証実験を日々繰り広げている状態です。

また、安全に関するティアフォーの取り組みを知ってもらい、安心を感じてもらうための取り組みとして、８月に日本語版、10月に英語版のSafety Reportを日本で初めて発行しました。この中にも記載がある通り、ティアフォーでは様々な環境下で自動運転が安全に運行できるかを細心の注意を払いつつ確認しながら、「自動運転の民主化」に重要な信頼を得るための実証実験をこれまでに約70回実施してきました。

ティアフォーが行ってきた実証実験実績

これらの実験において、ヒヤリハットはあるものの事故にいたる実験はここまでゼロとなっています。このような積み上げを行うことで、「自動運転車は定められた走行領域（業界用語でいうODD：Operational Design Domain）内であれば安全に走れるんだ！」という安心感を提供できていると考えています。

安全と安全性の違い

ここまでは、言葉遊びではないですが何となく感覚的な話をしてきました。しかし、Deep Techを目指すティアフォーでは、ここまでの内容をエンジニアリング観点で定量的に表現できるように再整理をしています。

安心は人が感じるか感じないかが判断基準になるので、アンケートなどによって評価することはできるかもしれませんが、基準が個々人の中にあるため完全に定量的であるかというと難しいところです。

安全・信頼を定量的に示したい場合には、「安全性」や「信頼性」と言った言葉で表現ができます。 この２つの言葉は国際規格であるISO、日本規格であるJISにそれぞれ定めがあり、ティアフォーではこれらを基に「安全性」について以下の通りまとめ直しました。

　安全性

• 人への危害または損傷の危険性が許容可能な水準に抑えられている状態
• 許容可能でないリスクが存在しないこと
• 人はミスをするまたモノは壊れるのでゼロリスクはない
• リスク（人への危害）をどこまで許容するか決定する

この定義では、「安全性」はリスクをどこまで許容するかを決定し、その範囲内での安全を確保することになります。一般的にALARP (As Low As Reasonably Practicable) と言われる手法で合理的に実行可能な最低の水準までリスクを低減することを目標とします。

許容できるリスクの線引きをするということは、リスク＝事故をゼロにすることを必ずしも目標にはしないということになります。「自動運転が実現すれば事故は完全にゼロにできるのでは？」と思うかもしれないのですが、不慮の事態などを考えると現実的にはこれを完全に実現するのはかなり難しいです。世の中一般に定められたルールの関係や「安全性」を高めるためのコストの問題など様々な制約があり、この制約内では100%リスクを減らすことは極めて難しいのです。そこで、この制約の中でどこまで「安全性」を高められるのかを線引きしていくことが重要となります。

ALARPの概念図

現にいまの人間が運転する自動車に関しても、どんなに安全に気を付けてても事故は起きてしまっています。そのような状況でも自動車が公道を走れているのは、法律などのルールや最新の安全装置などで社会として許容可能な安全を確保し、許容できないところに関しては、保険などといった制度側にリスクを転嫁することでリスクがコントロールされているからです。

ALARPを定量的に示すためには、許容可能なリスクの発生確率や損害程度を定量的に定めて総合的に許容可能な範囲を決めていくことになります。

この考え方に基づいた考え方がリスクアセスメントの基本となっており、自動車の機能安全規格であるISO 26262における自動車安全水準 ASIL (Automotive Safety Integrity Level) だったり、自動車のセキュリティ規格であるISO 21434のCAL (Cybersecurity Assurance Level)になります。

許容領域概念図

安全とコストとの考え方も上記でご紹介したSafety Reportの中で触れていますので、是非確認いただければと思います。

なお「信頼性」については、ISOとJISの定めを基にティアフォーでは以下の通りまとめ直しました。

　信頼性　

• アイテムが与えられた条件で規定の期間中要求された機能を果たすことができる確率
• 対象の損失コストを源流から抑えるもの
• ＝Reliability（信頼性・信頼度）＝Dependability ＝ 含 保全性（maintainability）や可用性（availability） 　

「信頼性」に関しては、主にサービスとしての可用性の部分で関係してきます。せっかく自動運転にしたのに稼働率が低く、メンテナンス工数がかかりかえってコストがかかるというような事態になってしまうと、それこそ企業としての信頼を損ねることになってしまいます。こちらについては、またの機会に詳しくご紹介したいと思います。

おわりに

今回は、安心・安全・信頼の言葉の違いやそれを定量化した時の考え方などをまとめました。ティアフォーの安全に関する考え方やこれから実現していきたいことに関してはSafety Reportにまとまっていますので、是非一読いただければと思います。

ティアフォーでは、自動運転の安心・安全を確保し「自動運転の民主化」をともに実現してくため、様々なエンジニア・リサーチャーを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです。

tier4.jp

2020年でKubernetesクラスターを3回再構築した話

こんにちは、Tier IVでMLOpsを担当している澁井（しぶい）です。
Tier IVには2020年9月に入社して、現在社歴2ヶ月です。Tier IVでは自動運転のための機械学習システムとオペレーションを開発しています。MLOpsでは機械学習のパイプライン開発から基盤構築、運用までをエンドツーエンドに行うのですが、MLOpsエンジニアは現状私一人で、寂しく気ままに開発しています。
前職ではECの会社でMLOpsとEdge AIを担当していました。基盤の一部にAWSのKubernetesマネージドサービスであるEKS (Elastic Kubernetes Service) を使っていたのですが、退職直前の2020年7月にそのKubernetesクラスターを再構築しました。2年越しで使っていたKubernetesクラスターが2クラスターあり、Kubernetesのコンポーネントがいろいろと古くなっていてアップデートができない状態だったため、再構築した次第です。結果として前職最後の仕事がKubernetesクラスターを2個作り直すというものになりました。作り直したKubernetesクラスターが元気に動いているか気になるところです。

さよならk8s

Kubernetesクラスター再構築はもう当面やらないだろうと思っていたのですが、つい最近またKubernetesクラスター（EKS Fargateクラスター）再構築をおこないました。何故Kubernetesクラスターを作り直さなければならなかったのか、AWS EKSやKubernetesの歩みとともに、振り返ってみたいと思います。

用語

Kubernetesを差す用語について、以下のように使い分けます。

• Kubernetes：Kubernetes一般
• Kubernetesクラスター：Kubernetesのクラスター
• AWS EKS：AWSのEKSサービス
• EKSクラスター：AWS EKSのKubernetesクラスター
• EKS Fargate：AWS Fargateで作ったEKSクラスター

Kubernetesと私

私はKubernetesを2016年頃から触り始めており、もうかれこれ4年もKubernetesとともに歩んできています。その間に私は転職を3回経験しましたが、仕事を辞めてもKubernetesだけは辞めずに使い続けています。検証目的を含めれば、私が作ってきたKubernetesクラスターの数は100を下らないと思います。

k8sと私

Kubernetesはコンテナをマルチサーバやクラウド環境で効率良く運用するためのコンテナオーケストレータです。Dockerに代表されるコンテナをサーバで動かし、複数のコンテナを複数のサーバで連携させるためのインフラや管理層を抽象化したミドルウェアがKubernetesになります。KubernetesはGoogle社内のBorgというコンテナオーケストレータプロジェクトが原点となっており、ここ数年で急速に発展、浸透してきているインフラOSSになります。私がKubernetesを使い始めた頃は構築スクリプトも用意されておらず、自分でネットワーク設計含めて手動でインストールする必要があったのですが、最近ではAWS、GCP、MS Azure等の主要クラウドでマネージドサービスが提供され、簡単に使い始められるようになっています。コンテナでシステムを作る用途ではとても便利で拡張性も高いミドルウェアなので、未経験の方はぜひ一度使ってみてください。

k8sの全体像

Tier IVではメインのインフラにAWSを使っています。その一部でKubernetesをマネージドサービスのAWS EKSで稼働させています。前職ではGCP＋AWSで開発しており、私はAWS EKSの経験もあります。実は前職の最後に作り直した2クラスターはEKSクラスターでした。作り直しの際にAWS EKSの使い方をいろいろと調べていたこともあり、Tier IVでもAWS EKSを使うことができて、とても馴染みやすかったです。再構築するまでは・・・。

ここ数年でKubernetesはどう変わったか

OSSとしてKubernetesの開発が始まってから6年ほど経っていますが、その間に多くの変化がありました。構築方法としてkubeadmが導入されたり、セキュリティとしてPod Security PolicyやNetwork Policyが導入されたり、LinuxだけでなくWindows Nodeがサポートされたりしています。Kubernetesの周辺機能でも、PrometheusとGrafanaによるログ監視機能、Istioによるサービスメッシュ、Knativeによるサーバレス基盤が開発され、KubernetesがProduction Readyなシステム基盤に成長しています。
Kubernetesの機能と同じくらい重要なのは、Kubernetesの実行環境としてマネージドサービスが主流になったことだと思います。インフラの主流がクラウドになっていったことと同様に、Kubernetesの主流もクラウド上のマネージドサービスになりました。クラウド上のマネージドサービスとして具体的なものを挙げると、AWSであればEKSやEKS Fargate、GCPであればGKE (Google Kubernetes Engine)、MS AzureであればAKS (Azure Kubernetes Service) です。それぞれのクラウドベンダーが自社クラウドに適したインテグレーションを進めており、Kubernetesのうまい使い方はマネージドサービスのうまい使い方になっていってます。
特にAWSではKubernetesのマネージドサービスとしてAWS EKSとEKS Fargateという2通りを提供しており、用途に合わせた選択が可能になっています。AWS EKSはKubernetesのコントロールプレーンのみをAWSが管理する方式で、Worker NodeやPod等のリソースはユーザが操作します。対してEKS Fargateではコントロールプレーンに加えてWorker NodeまでAWSが管理し、ユーザはノードレベルを気にせず純粋にKubernetesリソースの管理だけに集中できるサービスになっています。個人的にはノードインスタンス含めて管理したいので、AWS EKSのほうが好きですが、インスタンス管理が面倒であればEKS Fargateも良い選択肢です。

AWS EKS

AWS EKSではKubernetesクラスターの構築にはeksctlというツールを使います。ノードはAWS EC2を基盤とするため、オンデマンドインスタンスとスポットインスタンスをワークロードに応じて使い分けることでコスト削減ができます。メインのノードにはオンデマンドインスタンスによるマネージドノードを使いつつ、ジョブ等の一時的なタスクにはスポットインスタンスで立ち上げるというものになります。EKSクラスターのpodからAWSの他サービス（S3やRDS等々）を参照、操作するには、AWSのIAM (Identity and Access Management) ポリシーと連携するためにOIDC (Open ID Connect) を使用します。AWSでは各サービスへのアクセス許可をIAMで管理しますが、Kubernetesクラスターではリソースへのアクセス許可をRBAC (Role-based Access Control) で管理します。AWS IAMとKubernetes RBACを連動させる仕組みがOIDCになります。
これらのツールや構成は最近1,2年で整備されていったものです。それ以前に構築されたEKSクラスターでは導入できないツールもあります。たとえばeksctlというEKSクラスターの構築、管理ツールは、最初からeksctlでEKSクラスターを構築していないと使えないツールです。eksctlの登場以前に構築したクラスターにeksctlによるクラスター管理を追加導入することはできません。eksctlはyamlのマニフェストベースでEKSクラスターの構成を管理できるため、Infrastructure as Codeでクラスターを管理しようとすると必須のツールになります。EKSクラスターのIAM設定やノード管理もeksctlで実施できるため、EKSクラスター運用には欠かせないツールと言えます。
Kubernetesクラスターにデプロイされたリソースの管理にはWeave Fluxを使います。FluxはAWS EKS のKubernetesクラスターでGitopsを実現するツールで、Kubernetesクラスターのflux namespaceでリソースとして稼働します。FluxのDaemonsetがレポジトリをウォッチして、レポジトリにKubernetesマニフェストの更新があると自動的にKubernetesリソースに反映する仕組みです。Fluxは途中導入可能ですが、マニフェストがGit管理されていない状態から追加していくには手間がかかるのが実情です。
EKSクラスターを使うにはeksctlやFluxだけでなく、EKSクラスターと連携するAWSサービスを管理することも重要です。S3やRDSにデータを格納する構成や、外部からのアクセスを制限するセキュリティグループの適用等々、クラウドでKubernetesを使うためには周辺サービスとの連携が不可欠です。Tier IVではAWSの利用サービスはCloudFormationで構成管理し、Githubにマニフェストを保管する運用にしています。マニュアルで作ったAWSリソースをCloudFormation管理に置き換えることは困難であるため、やはりリソースを作る時点からCloudFormationを使うほうが便利です。
EKS クラスターをInfrastructure as Codeで管理するためにはeksctlによるKubernetesクラスター管理、FluxによるKubernetesリソース管理、CloudFormationによる周辺機能の管理が必要になるのです。

EKSとIaC

Kubernetesクラスター再構築

前置きが長くなりましたが、AWS EKSを効率的に安定運用するためには、eksctlやFluxを導入した運用設計を行う必要があります。既存のEKSクラスターがそれらのツールに対応していない場合、クラスター自体を作り直すことになります。
Tier IVでもどうやって作ったのかドキュメンテーションされていない（＝Infrastructure as Codeになっていない）EKS Fargateのクラスターがありました。社内向けのツールが稼働していることはわかっていました。EKSクラスターを運用管理していくために、私はクラスターを作りなおすことにしました。作り直したEKSクラスターをそのまま、今後私がTier IVで作る機械学習基盤に流用してしまおうという下心もありました。
私個人としては2020年に入って3回目（全部AWS EKS）のKubernetesクラスター再構築になります。前2回までのEKSクラスター再構築によって、AWS EKSを構築するために必要なツールは認識していました。会社やシステムの違いを吸収すれば簡単に再構築できると思っていました。しかしこの認識は裏切られました。

どう動いているのかわからないソフトウェア

最初に直面した課題は、既存のEKS Fargateクラスターで動いているソフトウェアがどう動いているのかわからないというものでした。EKS Fargateクラスター自体は半年くらい前に作られたものだったのですが、運用担当者がいない状態でした。急成長するテック・スタートアップでは稀によくあることですが、まずは作ることが優先で、運用は後回しになっている状態でした。
現状のKubernetesクラスターで動いているリソースや構成を整理する必要がありました。各namespaceで kubectl get ** や kubectl describe ** を叩きまわり、Kubernetesクラスター上で動いているリソースをyamlファイルにマニフェストとして出力することからはじめました。結果として以下のような構成であることが判明しました。

謎のEKS

Kubernetesクラスターで動くWebシステムとしてはオーソドックスなアーキテクチャーです。DjangoベースのWebフロントとRDS MySQLで構成されており、Django PodからPython KubernetesクライアントでJobを起動するワークフローになっています。マニフェストさえあれば再構築したEKSクラスターでも動かすことができそうに見えます。

謎の課金

インフラ再構築の基本として、ノードインスタンスとコンテナを整理していきました。既存のEKS Fargateクラスターで稼働しているPod数は3で、resource requestもCPUで合計5gに届かないくらいでした。EC2インスタンス換算でm5.largeタイプが3台程度で済むはずで、オンデマンドインスタンスでフル稼働しても$80以内に収まるものです。しかしなぜかAWSの課金コンソールでは月間$6,000程度発生する状態になっていました。
課金原因を調査すると、EKS FargateクラスターでKubernetes Nodeが100台ほど配備されていました。kubectl describe nodes でノード内のリソースを見てもPodは配備されておらず、不要なノードが延々と稼働している状態でした。EKS Fargateでは1ノードに1Podが稼働する構成になっていますが、Kubernetes Jobを起動すると、Jobを手動で消さない限り、CompleteしたPodがノードを専有し続ける仕様のようでした。Jobを起動すればするほど課金が膨らむ状態になっていたのです。前職でも似たようなKubernetes無駄課金がありましたが、転職先でも同じものを見るとは！？
この仕様はEKS Fargateクラスター特有のもので、EKSクラスターであれば発生しないものです。今回のEKSクラスター移行で不要ノードの問題は解決しました。

でもいろいろ書き換える必要があった

ソフトウェアのコードやKubernetesマニフェストを調べていってわかったことは、EKSクラスターだけでなくシステムの構成も見直したほうが良いということでした。具体的には以下のような課題が挙げられます。

1. インターネットからHTTPでアクセスされている。
   →　Route53でドメインを取ってACMで証明書を作って、HTTPSに変更する。
2. RDSのマスターユーザパスワードがGithubのプライベートレポジトリに入っている。
   →　AWS Secret Managerに移管する。
3. 監視がない。
   →　Datadog監視を追加する。
4. default namespaceにデプロイされている。
   →　プロダクト専用のnamespaceを切る。

これらをそれぞれで作成されるリソース単位でブレークダウンし、eksctlで管理するもの、Fluxで管理するもの、CloudFormationで管理するものに分類しました。EKSクラスター自体はeksctlのyamlマニフェスト、KubernetesリソースはFlux管理するKubernetesマニフェストになります。それ以外はすべてCloudFormationマニフェストにします。eksctlもKubernetesも、部分的にホストクラウドを操作する機能が備わっています。たとえばIngress ControllerはKubernetesからAWSのALBを配備します。このALBはCloudFormationの管理外になります。しかしALBへのアクセス制御は必要なため、CloudFormationでセキュリティグループのみ追加する必要があります。
新EKS クラスターの構築は以下の手順で実行しました。

1. CloudFormationでAWS VPCとサブネットを作成する。
2. eksctlでEKSクラスターを構築する。
3. KubernetesクラスターにFluxを導入する。
4. CloudFormationでRDSをスナップショットから作成する。
5. Fluxで必要なKubernetesリソースをデプロイする。
6. CloudFormationでRoute53、ACMからドメインと証明書を作成する。
7. CloudFormationでEKSクラスター、ALB、RDSへのアクセスをセキュリティグループで制限する。

eksctl、Flux、CloudFormationで管理するリソースとコンフィグレーションが一部重複するため、ツールを行ったり来たりしました。大変でしたが、新EKSクラスターを無事本番システムとして安定運用できる状態にしました。

まとめ

長くなりましたが、AWS EKSクラスターを年間で3回作り直した経験談でした。Kubernetesはここ数年で急速に発展したインフラMWであり、マネージドサービス含めてアーキテクチャーの変更が度々発生してきました。最近では仕様も安定しており、破壊的な変更も少なってきています。そのため、Kubernetes黎明期にチャレンジ精神で作ったKubernetesクラスターは再構築のタイミングにきているものがあると思います。ちょうど私はそのタイミングに3回遭遇しました。システム移行プロジェクトは生産性がなく、好きでないエンジニアも多いと思います。しかし私としては、地図のないダンジョンを探検しながら攻略していくゲームっぽさがあり、嫌いではなかったりします。
長くなりましたが、読んでいただきありがとうございました。

---

Tier IVでは、様々なエンジニアを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです！