グローバルサプライヤーがHCP Terraformを採用　長期的な視点でコミュニティ版からの移行を決断

自動車部品製造の知見を活かし、移動の価値を創造

トヨタグループのアイシンは「“移動”に感動を、未来に笑顔を。」というビジョンを掲げ、強みとなる自動車部品製造では電動化でカーボンニュートラルを目指すことや、これまで培ってきた技術やノウハウを活かして移動の安心安全を充実させることに注力しています。また事業ポートフォリオを従来からの自動車部品製造に加え、データ活用など新事業領域も拡大させることで「アイシンのフルモデルチェンジ」を目指しています。

自動車部品製造領域と新事業領域の両方でDX施策を推進するなか、欠かせないのがクラウド活用です。アイシンではCCoE（クラウド活用推進組織）を新設し、クラウド活用を促進するための施策を幅広く手がけています。たとえば、ユーザーの悩み相談やナレッジ共有するためのコミュニティ運営、全社共通クラウド基盤の構築、人材育成、セキュリティガイドライン策定などです。

作業効率と環境の一貫性を実現すべくIaCを採用

アイシンが早くから取り組んでいるデータ活用施策に位置情報活用プラットフォーム「Tatami」があります。これはカーナビはじめ自動車に搭載された各種機器から収集した位置情報や車両情報などを収集・蓄積し、ビッグデータ分析することで各種サービスにつなげるためのプラットフォームです。たとえば、アイシンが提供する自治体向け道路補修支援サービス「みちログ」はTatamiを基盤としています。道路管理者や道路補修者に効率的に情報を共有するためのツールとして、デジタル庁の技術カタログにも掲載されました。

Tatamiはアマゾン ウェブ サービス（AWS）をベースに、早い段階からクラウドのプロビジョニングにはTerraformでIaC（Infrastructure as Code）を実践しています。アイシン DXプラットフォーム部 CCoE室長 兼 コネクテッドソリューション部 主幹の福元将高氏は「IaCなしにクラウドを手動で構築するなど『ありえない』と思うほどIaCが定着しています」と言います。2024年度に稼働開始する社内クラウド基盤でもTerraformが採用されています。

Terraformを採用した理由として、福元氏は「AWSではAWS CloudFormationがあるものの、TatamiはAWS以外のサードパーティーツールも使用しているためTerraformが有利と判断しました。またTerraformはIaCのデファクトスタンダードという安心感もありました」と説明します。なおアイシン全体で見るとAWS以外にMicrosoft Azureを使用するプロジェクトや部署もあるため、マルチクラウド環境でIaCツールを一元化することを考えるとTerraformがさらに優位となります。

福元氏はIaCを実践する意義として、プロビジョニングの効率化はもちろん「環境差異をなくしてシステムの品質を担保する」ことも指摘します。システムやアプリケーションごとに必要な環境は1つではなく、それぞれ開発環境、検証環境、本番環境を用意する必要があり、全てに一貫性を保つ必要があるからです。作業の効率化と環境に一貫性を保つためにも、コードから環境構築する習慣はとても重要になります。

またIaCのコードは新しくチームに加わるメンバーの学びにも役立っています。福元氏は次のように説明します。「新しいメンバーにはTatamiのIaCコードを読み解いてもらうことにしています。クラウドのGUI管理画面を見ればどのような構成になっているのか把握できますが、クラウドとTatamiを理解するにはIaCコードを読み解くのがとても有効です」。

当初Tatamiではオンプレミス環境でコミュニティ版のTerraformを使用していました。福元氏は「最初はよかったのですが」と言います。課題となったのがTerraformそのものの運用管理。オンプレの自主運用では、環境構築にはじまり、バージョンアップに追従するなど運用管理に付随する作業が必要になります。福元氏は「本当にこの構成や設定が最適なのかという疑問がありましたし、使いこなそうとするとサポートが必要な時もありました」と振り返ります。

コミュニティ版からSaaS版のHCP Terraformへ

Terraformをコミュニティ版からHCPに移行することでTerraformの環境構築と運用保守から解放され、HashiCorpからサポートが得られたことに加え、コミュニティ版にはない機能も利用できるようになりました。

特に有益な機能だと福元氏が挙げるのが「Drift Detection」と、Sentinelの「Policy as Code」です。前者はTerraformのコードと実際に稼働しているクラウドのインフラを比較して、差異を検出します。一見必要ないと思えるかもしれませんが、現実的には運用に欠かせない機能となります。なぜならインフラをTerraformのコードで構築したとしても、長らく運用しているうちに何らかのきっかけで設定や構成が変わってしまったりすることがあるためです。しかしそれに気づくのは難しく、障害発生時には問題切り分けを難航させるリスクとなりえます。インフラがTerraformのコード通りの環境だと確認しておくことはガバナンス的にもセキュリティ的にも重要です。

後者は（SentinelのPolicy as Code）はポリシーの一貫性を保つのに有効な機能です。あらかじめ環境構築上のルールをSentinelで定義しておくと、違反があればTerraformが指摘するようになっています。