アマゾン ウェブ サービス ジャパン(AWSジャパン)は4月20日~21日の期間で幕張メッセにおいて「AWS Summit Tokyo」を開催した。本稿では「トヨタCCoEチームの挑戦 オブザーバビリティの活用とDevOpsの実現」をテーマにしたトヨタ自動車の事例を紹介する。
開発者自身が開発者のために最高の開発者体験をつくる組織
冒頭、トヨタ自動車 デジタル変革推進室 クラウドCoEグループ 主幹の内藤孝昌氏 は、同社内の最近の動向について触れた。現在、同社ではコネクテッドカーや自動運転、基幹システムを中心に“モビリティカンパニーへのフルモデルチェンジ”と“デジタル化”の取り組みが加速しており、これまでソフト開発がメインではなかった部門でもクラウド利用を含む新たな取り組みにチャレンジしている。
こうした現状をふまえ、内藤氏は「必ずしも良い側面だけでなく、ソフト開発やクラウドに慣れていないメンバーが増加し、セキュリティに対する懸念も増加しました。そのため、2022年4月にCCoE(Cloud Center of Excellence:クラウド活用推進組織)バーチャルチームを立ち上げました」と経緯を説明した。
チームのミッションは「安心して開発運用できるクラウド環境」と「クラウドに関する社内外の情報」を整備し、トヨタの全開発者がすぐに使えるようにするというもの。ビジョンは「ジャストインタイムで安心・安全なクラウド環境を提供する」「クラウドを使いこなすための技術支援・教育を提供する」「仲間といつでも相談できる場を提供する」だ。
同氏は「一言で表せばクラウドを活用して、開発者自身が開発者のために最高の開発者体験(DevEx)をつくる組織です。メンバーは10人ほどいますが、全員がプラットフォームやインフラを担当してきたわけではなく、アプリケーションを開発した経験があるメンバーです。開発者自身が社内で開発していく中で困ったことなどを技術的・プロセス的にも改善し、最高の開発者体験をつくる活動を行っています」と強調した。
CCoEの社内の立ち位置としては、ビジネス部門や開発部門などのクラウド活用組織と情報セキュリティ部門、経理部門、経営層といったクラウド管理部門の間に存在している。同チームではプラットフォーム開発・運用、プロジェクト支援、クラウド人材育成、コミュニティ形成・運用の4つの取り組みを行っている。
例えば、情報セキュリティ部門が作成しているガイドラインに対して改訂の提案や、ガイドラインの一部を適用したクラウドネイティブアプリケーションの開発・展開を加速させるプラットフォーム「TORO PF(Toyota Reliable Observatory / Orchestration Platform)」を開発・利用している。また、社内だけでなく、トヨタグループやクラウド事業者やパートナー企業など社外に対してもハブの役割を担っている。
TORO PFにより最短2時間でAWSアカウントを発行
TORO PFは、チームの立ち上げとともに本格的に開発を開始し、2022年下期に61プロジェクトで利用されている。内藤氏は「これまでは新規プロジェクトが中心となっていましたが、2023年度は既存のクラウド環境の移行を進めており、150プロジェクト程度まで増加が見込まれています」という。
同プラットフォームの特徴として、同氏は「2時間でアカウント発行」「セキュリティ設定工数96%減」「ガードレール型セキュリティ」「アプリ開発も支援」の4点を挙げている。
具体的には最短2時間、通常2営業日以内でAWSアカウントをユーザーに提供できるほか、アカウント発行時点でガイドラインの40%をカバーする基礎的なセキュリティ設定を実施。また、SSH/RDP(Remote Desktop Protocol)やAmazon S3のパブリック公開を禁止するなど、安全かつ開発者の邪魔をしないセキュリティとし、セキュリティも考慮したCI(継続的インテグレーション)/CD(継続的デリバリ)パイプラインで即デプロイを可能としている。
内藤氏は「TOROにより、すぐに開発に着手でき、アプリのコーディングからデプロイまでのスピードと品質が向上し、CI/CDが可能になりました。ただ、これで十分ではなく、CI/CDを1サイクルだけ狙っても意味がありません。重要なのは“継続的である”ことでした。これを実現するうえで、重要なピースとなったものがオブザーバビリティ(可観測性)。オブザーバビリティが最も得意とすることが継続的なフィードバックであり、DevSecOpsに対して効果的でした」と振り返る。
同氏は、サービスが適切に稼働しているか、エラーは出ていないか、パフォーマンスに問題はないか、ビジネスとして成長しているのかなど、顧客体験やビジネス状況を含めた可観測性が必要だと考えたという。そこで、New Relicが提供するオブザーバビリティプラットフォーム「New Relic」の導入に踏み切る。New Relicを選定したポイントとしては以下の4点だ。
1. 監視ツールの監視をしたくない
2. 顧客体験を重視したい
3. 多様なプロジェクトにマッチ
4. サポート体制
内藤氏によると、少ないCCoEメンバーで提供するため運用コストを最小化するべくSaaS(Software as a Service)がファーストチョイスであり、インフラの監視の延長ではなく顧客体験の監視を重視したかったという。その点、New RelicはAPM(アプリパフォーマンス管理)からスタートしたという強みがあった。
また、ユーザー数+データ量という課金体系が巨大組織特有の多様な要件に柔軟かつ即対応するという現状にマッチしたほか、ツールの使い方のサポートのみならず、CCoEという組織の成熟・成長観点でのサポートを備えている点を評価した。
New Relicの導入で実現できたこと
現在、CCoEではNew Relicを「TORO PF自体の監視」と「プロジェクトでの利用」の2通りで活用している。TORO PF自体の監視ではCCoEチームが利用し、インフラ監視が中心となっており、プロジェクトではTORO PFユーザーがアプリの監視を中心に利用している。
プロジェクト利用の支援内容はAWS Intergration設定、エージェント導入支援、サービスレベル/ワークロード作成、サンプルダッシュボード作成、アラート&AIサンプル作成、初期運用サポートとなり、そのうち内藤氏はAWS Intergration設定とサンプルダッシュボード作成を紹介した。
AWS Intergration設定は、基本的に同チームではインフラの構築を「Terraform」としており、ユーザーはアカウントが払い出されると、すぐにAWS側の情報を取得できる状況となっている。現在はTerraform Cloudのプライベートレジストリで管理しており、将来的にはセルフサービスにしていくことを検討しているという。
一方、サンプルダッシュボードの作成については、基本的な考え方として(1)顧客体験を重視、(2)表示内容を多くしすぎない(=見てすぐに状況を把握できる)、(3)顧客に近い指標から表示、の3つを挙げている。
内藤氏は「機能が多くても使わない機能が多く、毎日使う機能の体験が良いことが重要です。監視というとCPU使用率のイメージがありますが、顧客に影響が出なければ問題ありません。また、状況を把握できるように4つのゴールデンシグナル(レイテンシ、トラフィック、エラー、サチュレーション)のうち、トラフィックとサチュレーションが上がれば必然的にレイテンシとエラーも上昇することから、もし4つのうちどれかを選べと言われたら、レイテンシとエラーを選択します。さらに、最も顧客体験に近い指標としてフロントエンド、バックエンド、サーバ、データベースの順で表示するようにしています」と説く。
CCoEチームではダッシュボード作成に関して、New Relicの事前構築済みのダッシュボードとAWSの公式ドキュメントを組み合わせて、TOROサンプルダッシュボードを作成しているという。
プレゼンテーションの締めくくりとして、内藤氏は「New Relicの採用で顧客体験の観測が可能なオブザーバビリティの土台ができました。ただ、取り組み自体はスタートしたばかりのため、今後はオブザーバビリティやDevSecOpsの考え方やツール活用教育、コミュニティ形成などを進めていきたいと考えています。オブザーバビリティやDevSecOps、SRE(Site Reliability Engineering)の本質はツール活用の話ではなく文化です。良いツールを導入したとしても文化がなければ、活用することはできないことから、文化を形成するとともに組織としてオブザーバビリティを当たり前のものにします。そして、New Relicさんにはオブザーバビリティの民主化のための継続的なサポートを期待しています」と述べていた。