見出し画像

バックエンド&Webチームの利用技術のご紹介

(Sorry, English is not available yet. Japanese text only.)

こんにちは。日産自動車(株)の森下です。前々回の記事で紹介のあったバックエンド&Webチームに所属しており、NissanConnectサービス、販社向けNissanConnectシミュレータ、各種PoC活動や部門で利用するインフラの整備等にリードエンジニアとして関わっています。

今回は、自分が所属するチームで今どのような技術を利用しているかをご紹介します。個々の利用技術について掘り下げた記事はまた今後出てくると思いますので、今回は網羅的に全体像をご紹介できればと考えております。

どんな技術を利用しているのか?

バックエンド&Webチームが開発で何をどのように使っているのかをざっくりとご紹介します。大まかにでも雰囲気を感じ取っていただければ幸いです。

クラウド環境

主要なクラウド環境を使っています。大まかに以下のような用途になっています。

  • Microsoft Azure (以下Azure) : NissanConnectサービス、販社向けNissanConnectシミュレータのバックエンドを稼働させるインフラとして

  • Amazon Web Servces (以下AWS):PoC活動において開発したバックエンドを稼働させるインフラとして

  • Google Cloud Platform (以下GCP):Google Workspace, Firebase, データ分析やBIツールのホスティングなど

Azureについては管理運用を行ってくれている別部門があり、協力しあいながら利用しています。AWSとGCPは部門での利用でスモールスタートで使い始めつつ徐々に利用範囲が広がっていきそうな状況です。

アーキテクチャ

基本的にバックエンドのアプリケーションはマイクロサービスアーキテクチャで開発しています。1つのアプリケーションのコードベースを大きくしすぎず、ほどよく分割してデプロイして連携させています。トレードオフとして発生する複雑さやデプロイの手間などはCI/CDや監視などで補っています。ただしPoC程度の規模感では分け過ぎても手間が増えるだけだったりするので、あえてモノリシック的にしたりもします。

また、モバイルアプリケーションや対向システムといった連携対象ごとにBFF(Backend For Frontend)をAPI Gateway的に配置し、その裏にバックエンドのマイクロサービスを置く形にしています。現状ではRESTfulAPIの形でインタフェースを提供するのが主流ですが、PoC活動の中で試しにGraphQLでやってみたところフロントエンドとバックエンドの双方のメンバーでポジティブな感想が出ており、今後利用が広がることもありえると思います。

また、NissanConnectサービスではモバイルアプリケーションからできることをAmazon AlexaやGoogleアシスタントからも行えるスキルを提供しています。このスキルを実装するために各デバイスとNissanConnectサービスの橋渡しをするマイクロサービスを配置しています。

実行プラットフォーム

NissanConnectサービスと販社向けNissanConnectシミュレータのバックエンドアプリケーションはVMWare Tanzu Application Service (旧名のPivotal Cloud Foundryと言えば分かる人もいるかもしれません)というPaaSプラットフォームにデプロイして稼働させています。VMWare Tanzu自体の構築と運用は前述のAzureを担当してくれている部門が行ってくれており、我々のチームでもそこを使わせてもらっています。

PaaSはLinux VMやKubernetesを使う場合と比べて自由度が多少下がりますが、それよりも色々と自動化されることでインフラに近い層を自分たちで面倒を見なくても良くなるのが最大のメリットで、実際私のチームではサービスの開発に可能な限り集中したいので助かっています。

PoC系の活動では、DockerコンテナイメージをビルドしてAWSのECS / Fargateにデプロイして動かしています。VMWare TanzuはNissanConnectサービスに関連するプロダクトを稼働させるためのプラットフォームとして運用されているのでPoC目的では使いづらいのと、Dockerコンテナイメージとしておけばあまり環境依存もなく便利だし、自分たちが扱える技術をPoCをやりながら増やしていけるとなお良いだろうということで選択しています。

開発環境やコミュニケーションツール等

エンジニア個々人が使用する開発用の端末としては、基本的にMacBook Proを使用しています。統合開発環境としてはIntelliJ IDEA Ultimateを用意していますが、これは個々人の好みで例えばVS Code等のもっと軽量なものがよかったり他に使い慣れたものを選択する人もいます。

コミュニケーションツールとしてはSlack及びGoogle Meetを部門内ではよく使用しています。普段はSlackのチャットをメインで使いつつ、ちょっとした会話を少人数でしたくなったらSlackのhuddleを使い、人数多めなオンラインミーティングならGoogle Meetと使い分けています。

他にもConfluence, JIRA, Google Workspace等を使って情報共有やタスク管理などを日々の開発業務の中で行っています。

開発言語やフレームワーク

複数の開発言語を以下のように使い分けています。選択肢を絞りすぎず、でも発散しすぎないようにということで現状は主に以下4つにしています。絞りすぎないのはそれが何らかの理由で使えなくなった時のリスク回避のためであり、発散しすぎないというのは面倒が見きれなくならないようにという意図です。Goは好感触なところがあり今後利用が広がるかもしれません。

  • Java/SpringBoot:NissanConnectサービスのバックエンドの開発で使用

  • JavaScript/TypeScript/Node.js/React:販社向けNissanConnectシミュレータやVPAスキル(AlexaやGoogleアシスタント)の開発で使用

  • Python:PoCでまずは動くものを素早く作成したい場合などに使用

  • Go:PoCの中でせっかくなら利用技術の幅を広げたいという意図から初採用

CI/CD

ソースコードはGitHub上のリポジトリで管理しており、ソースコードレビューはPullRequest上で行っています。PullRequest作成時及びマージ時にはGitHub Actionsでビルドや自動テスト実行、タグ付けなどをおこなっており、ライブラリ等はGitHub Packagesに格納しています。このようにCI的なことはGitHub内で基本的に完結するようにしています。

CDについてはデプロイ先の環境ごとに仕組みが別れている形にとなっており、NissanConnectサービスであればAzure上に構築しているJenkinsを使っていますし、AWSであればCodeDeployを使うというような形でやっています。

また、GitHub上で開発ブランチをマージしたタイミングでスナップショットビルドを自動的に開発/テスト用環境にデプロイし、APIレベルでのブラックボックス自動テストを日々まわすことで品質確保を行っています。

運用

マイクロサービスアーキテクチャが抱える複雑性と向き合うにはObservabilityが重要になることを意識し、ロギング/トレーシング/モニタリングを行っています。

収集した情報をAzureのLog AnalyticsApplication Insightsを使って可視化したり追跡調査できるようにしており、数値を元にシステムの健全性だったり利用頻度が高くなる時間帯や季節などを見ています。アラートなどもそこで仕込んでおいてSlack通知するといったことを行っています。

また、実行時のエラーの発生頻度を抑えるための措置を自動で行うようにしていたり、障害発生時にSlack上から一部の運用操作を行えるようなChatOps的なことも行っています。

なぜ自分たちでやっているのか?

バックエンド&Webチームでは全メンバーが上記のような技術を使って自分たちの手でプロダクトの開発、運用を行っています。全てを自分達だけでやるには人手が足りないため、パートナー企業さんにもお手伝いしていただいていますが、あくまで自分たちでもやれるという前提でのことです。また、私の所属する部門には他にもPM, PO, UI/UX, モバイルアプリケーション開発のチームがあり、ユーザー体験を自分たちでデザインし、開発、運用する体制をとっています。

ハードウェアは開発されたものが生産されて初めて世に出ますが、ソフトウェアは開発したものをすぐ世に出せるという違いを、日産自動車という製造業の企業に入社して改めて実感しています。そのようなソフトウェアならではのアジリティの高さを活かして頻度高くリリースしていくには、やはり自分たちのプロダクトと技術を手の内化しているのが重要だと考えており、その姿勢を社内で実際に見せることで日産自動車のプロダクト開発がより良い形になることに貢献していきたいと思っています。

多少なりともご興味を持っていただければ幸いです。それではまた。