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

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

f:id:cvusk:20201104110828p:plain
さよならk8s

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

用語

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

Kubernetesと私

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

f:id:cvusk:20201104110853p:plain
k8sと私

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

f:id:cvusk:20201104110920p:plain
k8sの全体像

Tier IVではメインのインフラにAWSを使っています。その一部でKubernetesをマネージドサービスのAWS EKSで稼働させています。前職ではGCPAWSで開発しており、私は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も良い選択肢です。

f:id:cvusk:20201104110940p:plain
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による周辺機能の管理が必要になるのです。

f:id:cvusk:20201104110955p:plain
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ファイルにマニフェストとして出力することからはじめました。結果として以下のような構成であることが判明しました。

f:id:cvusk:20201104111014p:plain
謎の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では、様々なエンジニアを募集しています。もしご興味があればカジュアル面談も可能ですので以下のページからコンタクトいただければ幸いです!

初のTier IV Meetupを開催しました

こんにちは、ティアフォーでWebプラットフォーム開発を行っている関谷です。

8/18・8/19の2夜連続して、技術的な取り組みを紹介するティアフォー初のTech Meetupを実施しました。こちらはイベント直前の募集になったにも関わらず、200名を超える多くの方々にご視聴いただき、大盛況のうちに幕を閉じることができました。

また9/2にはティアフォーでの業務についてもっと皆さまに知っていただくために、Career Meetupを実施しました。

ご参加いただいた皆さま、Meetupの機会を提供いただいたTech Playの皆さま、どうもありがとうございました。

Day 1 - 世界初オープンソースの自動運転ソフトウェア「Autoware」ができること & 開発秘話 -

1日目は、弊社の起源でもあり、一番力を入れて開発している「Autoware」のアーキテクチャについてご紹介しました。

開発のリードをしている斉藤・堀部から、公開しているArchitecture Proposalの内容を中心に、全体の設計、PerceptionやPlanningといった各コンポーネントの内容についてそれぞれ説明いたしました。

 

質疑応答では、

  • 一番最初のデモ動画で出てきたような店舗内での自動化カートのようなものもAutowareで実現可能なのですか?
  • LiDARの干渉問題はどのように対処しているんですか?
  • MPCは最適化手法によって精度や処理速度が変わると思いますが、Autowareではどんな最適化手法を使っていますか?
  • ジャーク制約の中には、前後方向だけでなく横方向のジャークも含まれますか?

などなど、たくさんの方から様々なご質問を頂きました。

 

Day 2 - 自動運転を作るのはCloudシステムの集合体?? 活用技術を大解剖 - 

2日目は、Autowareの開発やAutowareを搭載した車両の運行を支える技術として、弊社で開発を進めているクラウドシステムWeb.Autoについてご紹介しました。

わたくし関谷と飯田から、Simulatorを含むAutowareのCI/CD基盤やMaaSアプリケーションと繋がる運行管理システムで使用している技術について説明いたしました。 

 

 

質疑応答では、

  • クラウドサービスの中から、AWSを選定した理由ってなんでしょうか?
  • CI/CDを1回走らせるのにかかる時間はどのくらいですか?
  • 緊急時に遠隔から車両の操縦を行うとのことでしたが、遠隔操縦特有の問題点としてはどのような点があるとお考えですか?
  • FMSはとてもサービス志向の機能に感じました。そうした機能の開発において、利用者側の嬉しさをビジネスモデルまで含めて提案するような活動もされているのでしょうか?

など、参加いただいた皆さまから色々なご質問を頂きました。

 

Day 3 - 自動運転の民主化を一緒に実現してくれるエンジニアを募集しています -

Career Meetupでは、ティアフォーの仕事内容や求人にある方々に参加登録いただき、質疑応答を中心に座談会のような形式で実施しました。

長丁場だったにも関わらず、皆さんからたくさんの質問をいただき、エンジニアの仕事内容・取り組み方や事業の内容、カルチャーについて知っていただく良い機会となりました。

 

まとめ

Tech Meetupの2日間でご紹介できた内容は弊社で取り組んでいる開発の一部に過ぎません。ティアフォーでは、研究からプロダクト開発といった様々なフェーズの研究開発を行なっており、各研究・開発で色々な試行錯誤を行なっております。

そういった取り組みをこれからもご紹介できるように、今後もTier IV Meetupを開催することを計画しています。次回開催が決まり次第、Twitterなどでご案内してまいりますので、ご興味がある方は是非弊社のTwitterをフォローしていただければと思います。

また、世界と戦える自動運転技術・サービス開発を進めていく仲間を引き続き募集しております。今回開催したMeetupやこのTech Blogで弊社での研究開発にご興味が湧いた方がいらっしゃいましたら、カジュアル面談も可能ですので以下のページからコンタクトいただければと思います。

tier4.jp

オフィス移転 品川オフィス

こんにちは、ティアフォーエンジニア兼引っ越し委員の伊勢です。

今回は技術情報ではなく、新オフィスの情報を皆さんにお届けします。

株式会社ティアフォーのオフィスは本郷3丁目から品川へ

国内・海外どちらからもアクセスしやすい品川です。 新幹線に乗りやすくなりました。

オフィス移転の背景には、社員数の増加、複数拠点オフィスの統合によるコミュニケーションの効率化、そして開発スピードの向上があります。

それでは、より便利に、より働きやすくなった新オフィスを紹介します。

新オフィス

エントランス

新オフィスはJR品川駅港南口から徒歩10分程度、品川インターシティの近くに位置しています。京急北品川駅からも近く、また天王州アイルからも徒歩圏内です! 1Fのビル受付を抜け、2Fのエントランスに入るとティアフォーロゴがお迎えしてくれます。

f:id:g-ise:20201005130715p:plain

エントランスはグレーと黒を基調としたシンプルかつクールなデザインとなっています。また、エントランス正面のカウンターはレセプションとしての機能だけではなく、イベント開催時にバーカウンターとしておもてなしにも使えるようになっています。

執務エリア

次に執務エリアを紹介します。

f:id:TierIV:20201008132005j:plain

当初構想では天井を抜いて開放感を出すことも検討したのですが、限りある予算をできるだけ従業員の使うものに積極的に投資することにしました。

そのため外観は普通のオフィスですが、長時間座っても疲れにくいヘッドレスト付きの椅子やダブルモニターでもスペースに余裕がある広い机、スタンディング会議室など、生産性向上への配慮が所々に細かくされています。また通路幅についても、移動しやすいようにそして移動時に他のエンジニアの集中力を妨げないように広めにとっています。

会議室

f:id:g-ise:20201005130858j:plain

旧オフィスと比較すると会議室の数がかなり増えました!

集中して物事を検討する時は壁に囲まれた会議室を、アイディア出しなどは開放感のあるガラス張りの会議室を使うなど、用途によって使い分けられるようになってます。私はスタンディングデスクのある小さい会議室が好きです。

大型の会議室では今後、「Tier IV X Research Seminar」や「Tier IV Academy」などの各種イベントを開催予定です。機会があれば是非いらしてください。

ガレージ

f:id:g-ise:20201005130927j:plain

新オフィスの目玉は1Fにあるガレージです。

以前は車両の整備などはオフィスから離れた別拠点で行っていましたが、車両とソフトウェアの開発を同一拠点で行えるようにすることで開発をよりスピードアップしています。

広い作業スペースでは車両の保管、メンテナンスだけでなくセンサーキャリブレーションの作業なども行えるようになっています。ガレージには、ティアフォーで開発している完全自動運転EV「Milee(マイリー)」や物流用ロボット「Logiee(ロージー)」、Autowareを搭載したJPN TAXI車両、遠隔操作用コンソールなどがあります。

f:id:TierIV:20201009075415j:plain

 

リフレッシュスペース

f:id:g-ise:20201005131016j:plain

続いてリフレッシュスペースです。 2Fはエントランスと会議室、リフレッシュスペースが割り当てられていますが、フロアの半分以上をリフレッシュスペースが占めています。広い空間で仕事を離れてゆっくり休憩できそうですね。

エントランスのシンプル、クールな洗練されたデザインとは対象的に、こちらは温かくリラックスできる雰囲気となってます。

個人的には隅っこの横になれるところがお気に入りです。昼寝やストレッチにも使えます。

f:id:g-ise:20201005131033j:plain

時々Logieeが走り周って衛生用品を届けてくれることも・・・。

 

もちろん今は難しいですが、MeetUpやHappyHourなどの社内外イベントの開催も想定しています。楽しみですね!

新オフィスでお待ちしております!

以上、新オフィス紹介でした。機会があれば是非見学に来てください!

またティアフォーでは、この快適かつ広いオフィスで一緒に「自動運転の民主化」を目指す仲間を絶賛募集しています。もしご興味があれば是非エントリーをご検討ください。

いつかこのオフィスで皆さんに会うのを楽しみにしています!!

www.youtube.com

自動運転における3次元での物体検出に画像データを活用する論文紹介

はじめまして、ティアフォーでパートタイムエンジニアをしている村松です。 

今回は、AutowareのPerceptionモジュールにおけるObject Recognitionを改善するために調査した内容について紹介します。 Autowareのアーキテクチャの詳細については過去の記事をご覧ください。

 

tech.tier4.jp

 

論文紹介

今回は、カメラ画像のみまたはカメラ画像とLiDAR点群の両方を活用した3次元での物体検出の論文を4つ紹介します。

 

Pseudo-LiDAR

まず最初に紹介するのは、カメラ画像のみを使って3次元物体検出をする手法です。この手法は、CVPR2019で採択された論文*1で、現在Teslaでも使われています。Teslaの取り組みについてはScaledML 2020でも発表されていますので適宜参照いただければと思います*2

一般的に、カメラ画像のみを使った3次元物体検出の手法はLiDAR点群を使った手法と比較してパフォーマンスが劣っています。この論文中では、その原因は画像から得られる深度推定の精度ではなくデータ表現の方法に問題があるとしています。一般的に用いられている深度マップ(Depth Map)による表現では、

  1. 物体の大きさが距離に依存する(例えば、遠くにあるものは小さく見える)
  2. 2次元空間上で隣接するピクセルが3次元空間上でも隣接しているとは限らない

という二つの問題点があることを挙げています。そこで、この論文では深度マップを点群と同様の3次元空間(xyz)で表現されるデータ形式に変換することを提案しています。

 

f:id:yukke42:20200907162401p:plain

 

f:id:yukke42:20200624150648p:plain

  

本手法の流れは次のようになります。

  1. 既存手法を用いて画像から深度推定を行う
  2. 深度マップをカメラキャリブレーションのパラメータを用いて3次元空間に投影することでxyzの点群データ(Pseudo-LiDAR)に変換する
  3. 得られた点群データ(Pseudo-LiDAR)について点群を入力データとする既存手法(PointPillarsなど)に与えることで3次元物体検出を行う

この手法の利点は、1ポツの深度推定と3ポツの3次元物体検出の手法を自由に変更できるというものです。そのため、既存の他の手法や将来のSotA(State of the Art)の手法に組み替えることが可能です。しかし欠点として、画像に対して深度推定と3次元物体検出の2つの手法を適用する必要があるため計算コストが大きくなること、そして点群を活用した3次元物体検出手法と比較した場合にパフォーマンスが劣っていることが挙げられます。

 

PointFusion

次に紹介するのは、カメラ画像とLiDAR点群の両方を活用した手法です。Zooxが公開した手法でCVPR2018で採択された論文*3で提案されています。なお、今年の1月には同社が本手法に関する米国特許を取得しています*4

画像と点群の両方をモデルの入力とする場合、この2つのデータ形式が異なるという問題があります。そのため従来の手法では、点群の画像への射影や点群のVoxel化によりCNNを適用できるデータ形式へと変換してデータ形式を揃え、画像と点群の両方の特徴量を活用していました。しかし、このデータ変換によりデータの質が落ちてしまうという欠点がありました。そこで本手法では、点群のデータ変換を行わずに特徴量を抽出して画像と組み合わせるネットワークを提案しています。

 

f:id:yukke42:20200624150731p:plain

 

本手法の流れは次のようになります。

  1. 既存手法(YOLOなど)を用いて画像から物体検出を行い、検出領域(2D Bounding Box)に対応する点群・画像領域を抽出(クロップ)する(図のA, Bの入力)
  2. クロップ点群・画像に対してそれぞれのネットワークを適用し特徴量を得る(図のA, B)
  3. 得られた特徴量を用いて、3D Bounding Boxの8つの頂点位置を推定する(図のC, D)

この手法は点群・画像に対し、一般的に使われているPointNetやResNetといったネットワークを適用して特徴量を得ています。そのうち点群から得られる特徴量に関し、点ごとの特徴量(point-wise feature)を用いるかどうかで2つのモデルを提案しています。

点ごとの特徴量を使う場合(図のC)には、図中のpoint-wise feature、global featureとblock-4の3つの特徴量を結合してMLP(Multi-Layer Perceptron)を適用することで8つの頂点位置とスコアを推定しています。その中で、一番スコアの高い点に対応する結果を最終的な出力として採用しています。また、ここでスコアの学習の仕方については2つの方法を提案しています。1つ目はsupervised socringとして各点が3次元領域内に含まれるかのバイナリ分類によって学習を行う方法です。2つ目はunsupervised scoringとして各点が3次元領域に含まれるかに関わらず良い位置推定となるものがスコアが高くなるように学習を行う方法です。

なお、点ごとの特徴量を使わない場合(図のD)には、図中のglobal featureとblock-4という2つの特徴量を結合してMLPを適用し8つの頂点位置を推定するというシンプルなモデルになっています。

本手法は、画像から検出された個々の物体それぞれに対してモデルを適用します。そのため欠点として、検出対象の物体数が増えると全体の実行時間が長くなってしまうこと、そして各物体間の位置や向きの関係を考慮できないということがあります。

 

Frustum PointNets

次に紹介するものも、カメラ画像とLiDAR点群の両方を活用した手法です。CVPR2019で採択された論文*5で、現在Lyftで使われている手法のベースになっていると思われるものです*6

点群を扱う手法として2016年にPointNetが提案されたことにより、点群のクラス分類とセマンティックセグメンテーションのパフォーマンスは大きく向上しました。しかし、この手法を点群全体に適用すると計算コストが高くついてしまいます。そこで、この論文では画像を活用することで点群を効率よく処理する手法を提案しています。

 

f:id:yukke42:20200624150823p:plain

 

提案手法の処理の流れとしては、

  1. 既存手法(YOLOなど)を用いて画像から物体検出を行い、検出領域(2D Bounding Box)に対応する点群を抽出(クロップ)する(図のFrustum Proposal)
  2. クロップ点群にセグメンテーションを行うことで、物体に対応する点群を得る(図の3D Instance Segmentation)
  3. 得られた点群から3D Bounding Boxを推定する(図のAmodal 3D Box Estimation)

となります。また本手法では、点群の処理をよりロバストに行うために各処理の間で座標変換を行なっています。その中でも大きなポイントとして、T-Netにより点群の重心が原点となる座標系(下図のc)から物体の中心が原点となる座標系(下図のd)へと変換しています。

f:id:yukke42:20200907122504p:plain

 

本手法についても、一つ前で紹介したPointFusionと同様に画像から検出された個々の物体に対してモデルを適用するため、物体の数に応じて実行時間が増えるという欠点があります。

 

PointPainting

最後に紹介するものも、カメラ画像とLiDAR点群を活用した手法です。nuTonomyが公開し、CVPR2020で採択された論文*7です。

 

f:id:yukke42:20200624150913p:plain

 

本手法の処理の流れとしては、

  1. 既存手法を用いて画像のセマンティックセグメンテーションを行う(図の①)
  2. カメラキャリブレーションのパラメータを用いてセマンティックセグメンテーションの結果を点群に投影しクラス情報を付加する(図の②)
  3. クラス情報が付加された点群を用い、既存手法による3次元物体検出を行う(図の③)

となります。

この手法は、画像から得た物体のクラス情報を点群に付与するため、PointFusion等の画像と点群の特徴量をネットワークの中間層で結合するような手法と比較し、センサーデバイスを変更した場合に生じるセンサー固有のパラメータ変化の影響を受けにくいと考えられます。 

また、CVPR 2020で開催された"Waymo Open Dataset Challenge"*8 で一位を取ったチームがPointPaintingを活用しています。解法のプレゼンはYoutubeで視聴できます*9このチームは、PointPaintingの応用としてセマンティックセグメンテーションだけでなく2D Bounding Boxを用いた手法を考案しています。このチームによると、2D Bounding Boxを用いた場合でもセマンティックセグメンテーションとほぼ同様のパフォーマンスを出すことができています。

 

さいごに

今回は、カメラ画像のみまたはカメラ画像とLiDAR点群の両方を活用した3次元での物体検出の論文を4つ紹介しました。最新のアカデミックの論文においては、点群のみの手法の方が画像のみの手法や画像と点群を用いた手法より性能が優れています。しかし、より安心・安全な自動運転の実現に必要となる様々な環境でよりロバストな物体検出を可能とするためには、点群と画像の両方を活用する必要があると考えています。

ティアフォーではAutowareのPerceptionモジュールを更に改善するために、引き続き調査および研究開発を行なっており、Perception Algorithms Researcherやパートタイムエンジニアなどを絶賛募集していますので、もしご興味があれば是非エントリーをご検討ください。

tier4.jp

*1:Wang, Yan, et al. "Pseudo-lidar from visual depth estimation: Bridging the gap in 3d object detection for autonomous driving." Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2019.

*2:https://youtu.be/hx7BXih7zx8

*3:Xu, Danfei, Dragomir Anguelov, and Ashesh Jain. "Pointfusion: Deep sensor fusion for 3d bounding box estimation." Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition. 2018.

*4:http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220200005485%22.PGNR.&OS=DN/20200005485&RS=DN/20200005485

*5:Qi, Charles R., et al. "Frustum pointnets for 3d object detection from rgb-d data." Proceedings of the IEEE conference on computer vision and pattern recognition. 2018.

*6:https://medium.com/lyftlevel5/leveraging-early-sensor-fusion-for-safer-autonomous-vehicles-36c9f58ddd75

*7:Vora, Sourabh, et al. "Pointpainting: Sequential fusion for 3d object detection." Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2020.

*8:https://waymo.com/open/challenges

*9:https://youtu.be/9g9GsI33ol8

ティアフォーにおけるシミュレーションを用いたCIの取り組み

こんにちは、ティアフォーでWebプラットフォーム開発を行っている徳永です。

今回は、自動運転システムの開発にWebの技術がどのように使われているかの一例として、現在弊社で開発しているシミュレーションを用いたContinuous Integration(CI)システムの概要を紹介したいと思います。

はじめに

警察庁の統計によると、2020年7月には24,951件の交通事故が発生しており、そのうち死亡事故が185件発生しています。

事故とまではいかなくとも、一歩間違えていれば事故になっていたヒヤリハットも発生しているでしょう。

自動運転車の走行においてはこういった事象が発生することは当然防がねばならず、人間が運転するよりもむしろ安全だという世界を作り出すことが一つのミッションであると言えます。

このミッションを達成するためには、事前に十分なテストを行い、 あらゆる状況に対応できるよう自動運転システムが進化していく必要があります。 

自動運転のテスト

自動運転においても、実車を用いたテストは重要です。実験場所に赴き、テストしたい状況を作り出し、自動運転車が意図通りに動作することを確認します。

しかしながら、雨や雪が降っている状況や、事故一歩手前のギリギリの状況など、全ての状況について実車を用いたテストを行うことは現実的ではありません。

一方、シミュレーションされた空間で車を走行させることができればこういった特殊なケースのテストも可能になりますし、もっとありきたりな状況であったとしても、実車を用いるより素早く多くの状況をテストすることが可能になります。

そのため、自動運転システムの開発ではシミュレータを用いたテストを行うことがとても重要となってきます。 

自動運転の仕組みとシミュレーションの分担

先日の記事でも紹介がありましたが、Autowareはいくつかのモジュールで構成されており、それぞれが役割・責務を負っています。

シミュレーションを用いてAutowareのテストを行う際、1種類のシミュレータで全ての機能をテストするよりも、それぞれのモジュールに対して最適なシミュレータを用いたテストを行うことで、より効率的にテストを実施することが可能です。

ティアフォーでは、以下のような分担でのシミュレーションの活用を考えています。

  • Log Simulator - Perceptionモジュールのテスト
    • 実際に計測したセンサやカメラなどのログデータを入力とし、それらの情報を基に周辺物体の検知・追跡・予測などを行うPerceptionモジュールに関するテストを行う。
  • Planning SimulatorPlanningモジュールのテスト
    • 物体検知などのPerceptionに関する情報は理想的な情報をダミーで与え、車両のPlanningに関するテストを行う。
  • E2E Simulator結合テスト 
    • Game Engineを用いた仮想的な3Dマップ内で仮想車両を走行させることで、現実を模した状況において、Sensing, Perception, Planningなど全てを対象としたテストを行う。また、ランダムな状況で長時間走行させることで、事前に想定することが難しいエッジケースの探索も行う。

これらのシミュレーションは、Autoware開発者がローカル開発環境での動作確認などで用いたり、あるいは各機能の実装時にProduct Ownerが受け入れ確認用として用いることなどが考えられます。

シミュレーションとContinuous Integration(CI)

自動運転ソフトウェアの開発で重要なことの一つに、日々の開発によって変化するソフトウェアの安全性をどう担保するかが挙げられます。ソフトウェアが日々変化していく際には、その過程で今まで対応できていたことに対応できなくなるなどのデグレードデグレ)が発生することも考えられます。

新しくリリースされたソフトウェアが実際の車両に適用されるまでにこれらを検知して着実に修正するためには、継続的にテストを実施し、常に既存のテストに合格している状態を保ちながら開発を行うことが必要となってきます。

こういった継続的なテストを一般的にContinuous Integration(CI)と呼びます。

CIによる安全性担保

Autowareは様々なノードから構成されているため、何かの拍子にデグレが入るという可能性もあります。もし、想定している機能が正しく動いていない状態で実車試験を行うと、想定外の挙動で事故に繋がることも考えられます。

こういったことをなくすため、ティアフォーではシミュレーションによるCIパイプラインを構築し、Autowareの開発を進めていく際に、前章のPlanning Simulatorによるリグレッションテストを回しています。

シミュレーションにおいて、他の車両の動きやAutowareによる自動運転車がどのような動きを行えばよいかを定義したものをシナリオと呼びます。シミュレーションによるAutowareの動作テストはこのシナリオを基に行っています。

テスト対象となるシナリオは、概ね以下のような流れにより登録されます。

  1. 自動運転車の走行環境(ODD)を定める
  2. ODDに準じたテスト要件を整理
  3. テスト要件から、使用する地図を定め、シミュレーションを行うシナリオを作成
  4. シナリオをシミュレータが読み込めるフォーマットで記述
  5. 作成したシナリオをシミュレータで実行し、シナリオが意図通り動作しているか確認
  6. CIとして登録し、以後リグレッションテストの対象シナリオとなる

現在、社内のCIシステムの中には、多くのシナリオが登録され、AutowareにPRが発行されたタイミングやリリースのタイミングで、自動的にリグレッションテストが回るようになっています。 Autoware開発者は自身がコードの変更を行った際にリグレッションテストの結果を参照し、自身のコードがデグレを発生させてないか確認することができます。

このように、CIを開発の軸に置くことによって、安全性を担保しつつもAutowareの開発スピードを落とさないような仕組みを日々試行錯誤しながら構築しています。

f:id:tkng-t4:20200901102418p:plain

CIのテスト結果を確認するWeb画面。 CIのWebシステムも日々更新されています。

シミュレーションの課題と技術的チャレンジ

シミュレーションを行うにあたり、解決すべき課題はたくさん存在します。

例えば、以下のような課題が存在します。

  • シナリオの記述そのものに時間がかかる
  • 特徴的なシナリオを事前に考えることに限界がある
  • GameEngineのシミュレーションを行う場合、3Dマップ生成に関するコストが高い

こうした課題を解決するために、Ontologyを用いたシナリオ自動生成(Ontology based Scene Creation for the Development of Automated Vehicles)や、HD Map(Paracosm: A Language and Tool for Testing Autonomous Driving Systems)またはログデータからシナリオ自動生成する手法などの活用により、シナリオをシステム的に網羅的かつ低コストに生成できないかを現在検討しています。また、3DマップについてもODDなどの要件から自動生成ができないかといったことを検討しています。

ティアフォーではCIとしてシミュレータを動作させるための基本的な部分の開発のみでなく、このような研究分野も調査し、より先進的で安全な自動運転の実現に向けた開発を日々行っています。

 

まとめ

ティアフォーでは、安全な自動運転社会の実現に向けて様々な取り組みを行なっています。本記事では幅広く紹介しましたが、それぞれの詳細な内容に関しては別の記事で紹介することができればと思います。

現在ティアフォーでは、自動運転システムはもちろん、それを支えるWebシステムを一緒に開発していく仲間も募集しています。もしご興味があれば是非エントリーをご検討ください!!

tier4.jp

 

プラットフォームOSの選び方

こんにちは、ティアフォーの伊藤です。

コロナで自粛中、テレワークに励んでいますが、つい時間を忘れて稼働時間が長くなってしまう今日この頃です。

私はAutowareのプラットフォーム開発を担当していまして、OSやROSといった低レイヤーの部分を中心に見ています。今回はそのOSの部分についてお話したいと思います。

さて、現在Autowareが公式にサポートしているOSはUbuntuになります。

Ubuntuはフリーで使用できる、とても有名なLinuxディストリビューションです。Autowareが研究段階の時から使用されています。

しかしながらAutowareを実用化するにあたり、今までなんとなく使ってきたUbuntuをこのまま使用し続けてよいのか、という議論がありました。

Linuxディストリビューションには3つの流派があります。

AutowareではDebian系のUbuntuを使っていますので、まずはDebian系の中でDebianUbuntuを比較してどちらを採用すべきなのかを検討していきました。 

Debian vs Ubuntu

検討では様々な側面について比較しましたが、その代表的なものを紹介したいと思います。

  1. ソフトウェアの安定性
    • Basic Foundation
      Debian Ubuntu
      • オリジナルのLinuxディストリビューション
      • unstableブランチから開発開始→ ReleaseCriticalバグなし → testingブランチに昇格 → フリーズ/チェック/細かいバグ修正 → stableとしてリリース。
      • ReleaseCriticalバグがなくなるまでリリースはされない。
      • ボランティアが活動の主体。
      • Debianをフォークしたもの(testingブランチをベースに開発)。
      • ユーザ指向、最新のハードウェアに対応、安定性に不安?
      • Ubuntu独自の修正もあり安定性に不安?
      • Canonical社が活動の主体(ボランティアも協業)。
      Ubuntuは安定性の面で不安視されていますが、別にテストされていないわけではありません。テストはCanonical社が行っていますので、この点については同等と言えるかもしれません。

    • Linux kernel
      Debian Ubuntu
      • 安定したkernelを導入する傾向。
      • ポイントリリースでkernelのバージョンを上げない。
      • 新しめのkernelを導入する傾向。
      • ポイントリリースでkernelのバージョンを上げてくる(メジャーバージョンを上げてくることもある)。
      Ubuntuはポイントリリースでkernelのバージョンを上げてきますが、その際にドライバも更新されてしまい、今まで動いていたものが動かなくなる可能性があります。もっとも自動更新をオフにしておけばよいですが、うっかり設定し忘れすることがあり、これは十分なリスクになり得ます。この点についてはDebianのほうが優勢と言えるでしょう。

      【補足資料:Software release timeline】
      各ソフトウェアのリリース日の関連性を以下にまとめました。
      UbuntuDebianに比べて新しいkernelを導入する傾向にあると思われます。

      f:id:ito--san:20200818113334p:plain


      【補足:CIPについて】
      なんとDebianには、CIP(Civil Infrastructure Platform)というDebianベースのSLTS(Super Long Term Support)があります。

      www.cip-project.org

      サポート期間が10年以上ありますが、対象はKernelとbusybox+αのみになります。そのため、このままでは対象が限定的ですので、他のパッケージもサポートを受ける場合、cybertrust社のEM Linux(有償)を導入する必要があります。または、自前でメンテナンスをしていく(セキュリティパッチをあてていく)ことになります。

      また10年以上も同じプラットフォームを使い続けるのか、という問題もありますが、工場等の設備には非常に適しているディストリビューションと言えるでしょう。

      なお、CIPとコラボレーションする予定のプロジェクトに、ELISA(Enabling Linux In Safety Application)というものがあり、こちらはセーフティ分野においてシステム構築や認証を支援するツールやプロセスを作成するオープンソースプロジェクトです。CIPを使うならばELISAに参画したり何らかの形でコラボレーションすると、機能安全に優れたアプリケーションを開発できるかもしれません。
      以上、少し話がそれてしまいました。

      elisa.tech

  2. プロダクト計画との親和性
    • Release cycle
      Debian Ubuntu
      • リリースはあらかじめ計画されておらず、プロダクトのリリース計画が立てづらい、と言われている。
      • 歴史的には2年おきのリリース。
      • ポイントリリースは不定期(ミスが判明してすぐ再リリースすることもある)。
      • リリースはあらかじめ計画されており、プロダクトのリリース計画が立てやすい。
      • ポイントリリースもあらかじめ計画されている。
      バグがなくなるまでなかなかリリースされないことが、かつてのDebianのデメリットでした。Ubuntuはそれを解消するために計画重視のリリースになっています。どちらかというと、ディストリビューションのリリース計画があらかじめ決まっていたほうが、プロダクトへの導入計画も立てやすいですね。

       

  3. サポートおよびサポート体制
    • Support period
      Debian Ubuntu
      • フルサポート3年。
      • 無償セキュリティアップデート2年。
      • 対応はボランティア次第のところもある。
      • 対応に関心のある企業がお金を出してサポートさせる場合もある。
      • プロプライエタリ系の対応は遅れる。
      • 無償セキュリティアップデート5年。
      • 追加で5年間の有償セキュリティアップデートを受けることが可能。
      • バックにCanonicalの強み。
      • プロプライエタリ系もCanonicalが手を回して対応させる場合もある。
      • NVIDIAのデフォルトOSがUbuntu
      • Tensor FlowもUbuntuをサポート。
      サポートの面からするとバックにCanonicalがいるUbuntuのほうがサポートが厚そうに見えますね。

  4. ROSとの親和性
    • Target platform
      Debian Ubuntu
      • ROSのサポート期間が2つのDebianサポート期間にまたがった場合は、最初のDebianのみをサポート。
      • ROS2の主要なプラットフォームはCanonicalUbuntuリリース。
      ROS2のプライマリプラットフォームは、Ubuntuと定められています。Autoware AutoはROS2を使用していますので、自然にそれに習うという感じになるでしょうか。

    • Buildfarm
      Debian Ubuntu
      • 自らCI環境を構築する必要性がある。
      • CIでエラーが発生した場合の対処とOSRFへの働きかけが必要。
      OSRF側でUbuntuを使用してCIを回しているので安心ですね。ただ、DebianでもCI環境を構築できますし、OSRF(Open Source Robotics Foundation)とCIに関するノウハウを共有できたりと、OSRFに貢献をしていきたい場合はDebianもよいかもしれません。

  5. OTAとの親和性
    • Snap
      Debian Ubuntu
      • Snapは使用可能だが、OTA用のシステムは自ら構築する必要がある。
      • 有償サポートでPrivate StoreやCIを使用可能。
      • Public Storeで問題なければ無料で使用可能。
      OTAでSnapを使用する場合、自前でソフトウェアのアップデートシステムを構築するパワーがあればDebianでもよいと思います。それに対し、Public Storeで一般公開しても問題がないとか、Private StoreやCIを手っ取り早く使いたい場合はUbuntuでもよいと思います。こちらは製品の開発方針に拠るところがありまして、優劣はつけ難いです。

  6. 使用しているユーザー数
  7. プラットフォーム移行にかかるコスト
    • コスト
      Debian Ubuntu
      • かかる。
      • 開発者全員に波及する問題。
      • ほぼゼロ。
      実はティアフォーの開発者は皆Ubuntuを使用しておりまして、Debianへ移行する場合は、大きなコスト(時間)がかかってしまいます。したがって、Ubuntuの場合は現状のまま使い続けていればよいのでコストはかかりませんね。

まとめ

以上、いろいろな側面からDebianUbuntuを比較していきましたが、オープンソースとしてまずAutowareを普及させたいことを重視して、

  • ROS2の主要なプラットフォームはUbuntuなので、まずはAutowareもUbuntu上で動作させるべき。
  • Ubuntuは利用者数が多くCommunityも大きいので、Autowareの普及をより最大化できる。
  • 途中でkernelが更新されるなどUbuntuにもデメリットはあるが、なんとか運用でカバーする。

という理由から現状はUbuntuを選択しています。

ただ、Ubuntuに替わるOSが台頭してくるようになれば、Autowareエコシステムの基盤になる可能性も十分にありますし、積極的に検討していきたいと考えています。今後とも様々なOSの動向を注視していきたいと思います。

最後に

ティアフォーではオープンソースの自動運転ソフトウェア「Autoware」だけではなく、Autowareを下支えするROSやプラットフォームOSの開発や性能改善等も行っております。今回はLinuxについて触れましたが、RTOSの研究や採用検討も進めております。

ティアフォーではAutowareを下支えすることができる優秀なプラットフォームエンジニアも募集していますので、もしご興味があれば是非エントリーをご検討ください。

tier4.jp


※本記事に記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。

 

ドメイン駆動設計による運行管理システムのアーキテクチャの最適化

こんにちは。ティアフォーでWebサービス開発を担当している池谷です。

世の中はコロナで自粛モードが続いていますが、ティアフォーではリモートワークを活用し日々の業務に柔軟に取り組んでいます。

さて、私の所属するWebチームでは、オープンソースの自動運転OS「Autoware」を利用した多種多様なサービスを開発しています。その中でも代表的なサービスに「FMS」という運行管理サービスがあります。今回は、当サービスを開発してきた振り返りとして、主にドメイン駆動設計によるアーキテクチャの最適化に纏わるトピックについてお話したいと思います。

What's FMS?

tech.tier4.jp

過去にも一度ご紹介させていただきましたが、FMS(Fleet Management System)とは、業界的には「配車サービス」や「運行管理サービス」と呼ばれており、複数の車の走行予定・計画などを管理するサービスです。

例えば、海外ではUber社などが配車サービスを展開しています。国内にも配車サービスビジネスを展開しているプレイヤーは存在します。

ティアフォーのFMSの注目機能

弊社のFMSが運行管理サービスとして特殊な点は以下の通りです。

  • 管理する車が自動運転車である
  • ハイブリッドな運行モデルの走行管理が可能である

運行管理サービスというと、車両に一般的な自動車を用いる場合がありますが、弊社の場合はAutowareの自動運転技術とWeb技術をインテグレーションすることで、自動運転車を使った運行管理サービスを実現しています。

また、FMSは複数の運行モデルに対応しています。運行モデルというと聞き慣れない言葉かもしれませんが、モデルによって以下のような違いがあると認識していただければと思います。

オンデマンド配車モデル

f:id:hikeya:20200508130132p:plain

例えば、自分が今いる場所まで車で迎えに来てほしい人がいた時に、まずその人がいる地点に車を迎車させ、その後目的地まで送り届けるといった車両スケジュールを管理します。

旅客ビジネスや配車ビジネスの場面において求められる運行モデルです。

巡回走行モデル

f:id:hikeya:20200508130208p:plain

一方で、巡回走行モデルは決められた地点を延々と周回するような運行モデルです。

こちらは、工場などの物流ビジネスの場面で求められる運行モデルです。

ベストプラクティスを求めて

FMS開発における試行錯誤

自動運転やMaaSの分野は歴史が浅いこともあり、FMSを含めたWebサービスデザインパターンが確立されていないのが実情です。そのような中、開発にあたっては常に自分達にとってベストな形を模索してきました。

FMSはこれまでに2度に渡る変遷を遂げています。第1の転換期は、α版からβ版への変更で、機能面の拡充サービスとしてのスケーラビリティなどの非機能向上を目的にシステム再構築を実施した大イベントです。現在のFMSの礎はここで構築されました。

しかしその後、マイクロサービスとしての設計上の問題などが影響し、次第にバグが増加したりシステムの保守性が低下していきました。そこで、こういった課題を解決すべく実施したのがアーキテクチャの最適化です。これが第2の転換イベントです。今回はこのイベントにフィーチャーしたいと思います。

f:id:hikeya:20200424182553p:plain

浮上していた課題

具体的には、β版は次のような課題を抱えていました。

  • マイクロサービスにおけるコンポーネントのメッセージング・I/Fが密結合してしまっていた
    コンポーネントに閉じた修正のはずが他のコンポーネントに影響しデグレが発生
  • リファクタリングが不足し変更容易性が低下していた
    機能追加や機能変更時に必要以上に時間を消費
  • システムとして仕様の明記や用語の整理が不十分なために全体の理解容易性が低下していた
    新しい開発者がキャッチアップに躓いたり属人化の傾向が出ていた

これらの課題を解決するために、アーキテクチャを俯瞰的に見直し、各コンポーネントリファクタリングや再開発を実施しました。

開発手法のアプローチ

ドメイン駆動設計

アーキテクチャ全体の見直しにあたって、開発手法としてドメイン駆動設計を取り入れました。人気度が高く話題に上がることの多いDDDですが、DDDを採用した理由は、次の利点に惹かれたところが大きいです。

  • 変更容易性が高い
  • 顧客やチームメンバーと共通認識を持ちやすい

FMSではモビリティやAutowareに纏わる専門用語を多く扱います。

  • 例:Waypoint, Lane, LatLng, MGRS, ETA, Dispatch など

こうした専門用語のキャッチアップが、新しくジョインしたエンジニアが最初に躓くポイントになっていました。

DDDでは、ユビキタス言語というユーザーと開発者で互いに通じる用語に関する内容が登場しますが、これはユーザーのみならず、例えば他の開発メンバー達とも理解が促進されるものと思われます。これにより、上述の障壁を少しでも軽減したいと考えました。

また、FMSの開発チームでは、スクラム開発におけるフィーチャーチーム体制を導入しており、みんなで一緒に複数のコンポーネントをクロスファンクショナルに開発し合うスタイルを取っています。共通の認識を持てる言葉ができることでコミュニケーションが捗り、その結果チーム開発のアジリティ促進効果を期待できると考えました。

モデリングの実践

ではここで、車両のスケジュールを管理するSchedulerコンポーネントに対して実際に行ったモデリングについてご紹介します。

f:id:hikeya:20200501165836p:plain

f:id:hikeya:20200501165920p:plain

f:id:hikeya:20200501165947p:plain

これらは、Schedulerが管理する最も基本的なドメインモデルです。スケジュールは、ステータスや走行の予実などを管理しますが、その他に別のドメインモデルであるタスクも管理していますね。こういった複数のモデルやオブジェクトを一つのまとまりとして管理することを「集約」と言います。

このように整理することで「タスクの○○の部分を☓☓に変更しておいて」「ああ、タスクね」といったコミュニケーションが可能となります。

設計・実装面のアプローチ

クリーンアーキテクチャ

Schedulerですが、以前は一般的なレイヤードアーキテクチャでしたが、DDDを具現化するために、DDDと相性が良いと言われるクリーンアーキテクチャを取り入れて再開発を行いました。

Clean Architecture 達人に学ぶソフトウェアの構造と設計
 
採用根拠

DDDの実装手段としては、クリーンアーキテクチャ以外にも候補はありましたが、大きな動機としてはやはり変更容易性の高さが決め手となりました。

f:id:hikeya:20200501180845p:plain

f:id:hikeya:20200507183113p:plain

Schedulerは、機能開発のボリュームは実はそれほど多くはありません。ある程度機能面での補完が終わったら、その後はスケジューリングの最適化問題などに対する試行錯誤が想定されます。

例えば、オンデマンド配車のユースケースを想定すると配車依頼がかかった時に、最適な車両を配車させるニーズが生じます。本格的に対応するには、離散最適化などの高度なコンピューターサイエンスが要求されます。こうした変更開発の比重が大きくなりそうなシステムの開発においては、変更容易性の高さを享受できるクリーンアーキテクチャは合理的だと判断しました。

新しくなったFMS

アーキテクチャ

f:id:hikeya:20200507193111p:plain

こうして、開発手法および技術の刷新によって新しくなったFMSの姿がこちらです。それぞれのコンポーネントが独立し、それぞれの責務を果たすアーキテクチャへと変貌を遂げました。

序盤に挙げた以下3つの課題ですが、まだ完全に解決できた訳ではありませんが、着実に進歩したものと感じています。

  • バグの多発
  • コンポーネント変更容易性の低下
  • システム全体の理解容易性の低下

この他にもまだ課題はありますが、現在はこのアーキテクチャをベースに新機能の開発や非機能の拡充に励んでいます。

開発手法や技術の選定にあたってのご注意

今回採用したDDDやクリーンアーキテクチャですが、勿論良い面ばかりではありません。例えば、ある程度規模感のあるシステムでないと、旨味が少ない割に開発コストばかり高くついたり、変更が少なかったり寿命が短いシステムにおいて、変更容易性はあまり重要ではないという考え方もできます。

この辺りは、良い面と悪い面をしっかりと理解した上で、自分達のシステムとの相性を見極めてから採用されることをお勧めします。

最後に

今回は、マイクロサービスのアーキテクチャ最適化について、代表的なサービスをベースにご紹介させていただきました。こう見えてFMSはまだまだ開発途上なサービスです。また、FMS以外にもWebチームではバラエティに富んだサービスを鋭意開発中です。

ティアフォーでは、これらサービスの開発を加速していただける優秀なソフトウェアエンジニアを募集しています。

Careers | Tier Ⅳ, Inc.