重厚長大な企業の内製開発組織で成果を出すためのサーバーレスアーキテクチャ / ServerlessDays Tokyo 2023

2023年9月23日に発表した「ServerlessDays Tokyo 2023」の発表資料です

Transcript

1. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 重厚長大な企業の 内製開発組織で 成果を出すための サーバーレスアーキテクチャ 2023/09/23 三菱重工業株式会社 デジタルイノベーション本部 DPI部 SoEグループ CXチーム 山田 悠太
2. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 2 今回の発表は個人の見解であり、所属組織を代表するものではありません 免責事項
3. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 3 山田悠太 (@mongolyy) あだ名: モンゴル プロフィール 三菱重工業株式会社 デジタルイノベーション本部 DPI部 テックリード 好きな言語: Scala 最近触っている技術スタック: TypeScript, React, Next.js
4. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 4 お伝えしたいポイント ➢ やってみてどうだったか、どういう難しさがあり、どういう工夫をしたか？ ➢ 大企業の内製開発組織での事例紹介 • Webアプリケーション開発の技術選定（アプリケーション編） • サーバーレスアーキテクチャ（周辺モジュール編）
5. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 5 “弊社製品のユーザー様向け 消耗品見積・発注サイト” プロダクト概要 プロダクト これまでは電話、メール、FAXでやり取りしていた
6. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 6 プロダクト概要 アーキテクチャ概要 Copyright©2018 Hasura(Released under the MIT license)https://opensource.org/licenses/mit-license.php
7. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 7 プロダクト概要 事業部門 ビジネスオーナー プロダクト オーナー 開発者 チーム体制 プロダクト開発チーム 弊社製品の ユーザー デザイナー
8. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 8 大企業の内製開発組織での難しさ ➢ エンジニアが少ない ➢ エンジニアのバックグラウンドが異なる • 3人 • Scalaエンジニア • C#エンジニア • JavaScriptエンジニア 内製開発組織ゆえの難しさ 大企業ゆえの難しさ ➢ 複雑な業務フロー、業務ロジック • 複雑な料金計算ロジック、検索、 権限制御 ➢ 基幹システムとの連携 • ERPと相互にデータ連携する必要がある 制約がある中、実績、成果を出すことが求められる
9. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 9 大企業の内製開発組織での難しさに対してどう考える？ ➢ エンジニアが少ない ➢ エンジニアのバックグラウンドが異なる • 3人 • Scalaエンジニア • C#エンジニア • JavaScriptエンジニア 内製開発組織ゆえの難しさ 大企業ゆえの難しさ ➢ 複雑な業務フロー、業務ロジック • 複雑な料金計算ロジック、検索、 権限制御 ➢ 基幹システムとの連携 • ERPと相互にデータ連携する必要がある なんとかなりそう 少人数で開発・運用・保守できることをまず考えた
10. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 10 少人数で開発・運用・保守できることをまず考えた アプリケーション編
11. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 11 それまでの自分たちの手札を並べて考えてみる ➢ ノーコード、ローコードツール ➢ 複雑な料金計算ロジック、検索、権限制御の実現が難しく、要件が満たせない可能性があった ➢ SPA （Vue.js） + バックエンド（Python） ➢ 該当の言語、ライブラリに精通しているメンバーがおらず、リスクになる可能性があった ➢ サーバーサイドとフロントエンドで異なる言語を使用する場合、学習コストが大きい 当時（2021/1）の部内での技術スタック 自分自身の手札 ➢ Scala + Play Framework もしくは Ruby on Railsで作る ➢ 他2名がC#、JSのエンジニアであることを考えると、学習コストが大きいと判断
12. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 12 もっといい方法がないか…
13. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 13 Headless Commerceとの出会い DB 管理画面 API Headless Commerce フロントエンド クライアント ✓ フロントエンドは使い勝手に直結するので、実装する必要がある ✓ バックエンドはSaaSを使用することで、実装を薄くできる （SaaS） （スクラッチ）
14. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 14 SaaSをバックエンドにしてみることを考えてみる ➢ 実装するのはフロントエンドのみ ➢ フロントエンドの技術に精通すればいいので学習コストは減る ➢ TypeScriptはJava, C#とも書き方が近かったので、 メンバーの中でReact + TypeScript採用でスムーズに開発が開始できそうな感覚があった ➢ SaaSの使用 ➢ 基幹システムとSaaS（kintone）で連携実績があった 3つの課題が解決できるのでは？ ➢ エンジニアが少ない ➢ エンジニアのバックグラウンドが異なる ➢ 複雑な業務フロー、業務ロジック ➢ 基幹システムとの連携
15. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 15 SaaSをバックエンドとしたときの懸念もある ➢ SaaSにはAPIの呼び出し回数に制限が存在する ➢ 採用を検討したkintoneの場合は1アプリ(≒1テーブル)当たり10,000回/日 ➢ ユーザー数、利用頻度考慮し、リクエスト数は多く見積もっても5,000回/日 APIのRate Limitの問題 パフォーマンスの問題 ➢ 部品の点数が数万点で、数万レコード登録されている場合にSaaSの性能がどうなるか懸念があった ➢ kintoneに50万レコード登録してみて100レコード取得で計測したところ300msであった ➢ 非機能要件として、FMP 2sを目標としていた 要件と照らし合した結果、問題ないことが確認できた
16. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 16 やってみる！
17. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 17 採用技術について ➢ TypeScript ➢ 開発者全員が、型宣言できた方が開発しやすいという意見だった ➢ React ➢ チームメンバー、同僚にReactの経験者あり ➢ Next.js ➢ SSRが簡単に使える ➢ kintoneのAPIへのリクエストするにあたり、 サーバーサイドでのデータ取得は必須だった ➢ Vercel ➢ CD環境構築の開発者体験が良かった ➢ PaaSであり、開発者はインフラの運用作業がほとんどなくなる SSR or API 少人数で開発・運用・保守できることを考えた React logo©React(Licensed under CC BY 4.0）https://creativecommons.org/licenses/by/4.0/
18. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 18 ➢ 開発着手から半年でv1がリリースできた ➢ 技術を絞ったことでv1リリース時点でテストカバレッジ(C1)は約90% ➢ TypeScript, React, Next.js, Vercelは想定通りスムーズに使用できた ➢ SSRを使用しているので、パフォーマンス(FCP)は悪かった(1s~) どうだった？ 全般 React kintone ➢ 状態管理が必要なページはあまりなかったのでReact自体の恩恵はあまりなかった ➢ 基幹システムに存在しないデータ種別は、kintoneの管理画面を使用して登録してもらった ➢ テーブル構造のコード化が難しかったので、テーブル構造とコードの整合性の維持に注意を払ったり、 APIを呼び出すコードにおいて値のチェックが必要になった ➢ kintoneを仮想環境で動かす手段は提供されていないので、テストが難しかった ➢ このような使われ方は想定されていないので仕方ないという理解 ➢ APIを呼び出すコードのみを関数化し、ロジックをなるべく排除するようにしてテストの対象外と した（Humble Objectパターン）
19. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 19 少人数で開発・運用・保守できることをまず考えた 周辺モジュール編
20. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 20 周辺モジュールのサービス選定 少人数で開発・運用・保守するために、積極的にSaaS、FaaSを採用 ➢ auth0 ➢ 認証基盤として部内で使用実績があったため採用 ➢ SendGrid ➢ 他のメール配信SaaSと比較し、自分たちの想定する使い方において、APIが一番使いやすかったため採用 ➢ algolia ➢ kintoneの検索機能が要件を一部満たせなかったため検索SaaSを検討 ➢ 他の検索SaaSと比較し、自分たちの想定する使い方において、APIが一番使いやすかったため採用 ➢ Lambda ➢ SaaS単体だけでは要件を満たせない場合 (algoliaの検索インデックス構築や定期的なメール配信といったバッチ処理)に、Lambdaを使用した
21. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 21 どうだった？ ➢ 認証機能を1日でローカルで動かせるようにし、1週間で本番環境で使えるようにできた auth0 ➢ メール送信機能を1日で組み込めた ➢ メール開封率が確認できるようになっており、使用状況の把握が簡単にできた SendGrid ➢ 検索ワードが簡単に確認できるようになっており、使用状況の把握が簡単にできた ➢ レスポンスが爆速だった（数十ms～数百ms） ➢ 部分一致検索などRDBと勝手が違うところがあり、調査、検討が必要であった algolia ➢ アプリケーションと同様の言語であるTypeScript、JavaScriptを使用して実装。 Lambda、SAMのキャッチアップだけで開発できたので、学習コストが小さかった。 Lambda ➢ 帳票SaaSの採用も検討したが、見積書のフォーマットに関する要件が厳しく断念 その他
22. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 22 この時点でのアプリケーションのアーキテクチャ（v1.0）
23. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 23 でもまだ課題はあった…
24. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 24 課題と解決策 ※ kintoneに問題があるわけではなく、私たちの使い方が特殊であるがゆえの課題 ➢ 多事業部展開 ➢ 他の事業部とのデータ連携をする場合、RDBを使用した方が調整がスムーズ ➢ 基幹システムは事業部毎に異なり、kintoneとの連携実績があったのはレアケース ➢ テーブル構造とコードの整合性の担保 ➢ マイグレーションの仕組みが存在せず、kintoneとコードのスキーマの一致に 注意を払う必要があった ➢ テスタビリティ ➢ Docker上でkintoneを立ち上げる仕組みは無いので、DB層も含めたテストが難しい ➢ その他 ➢ チームメンバーのスキル的に、新しい技術を習得する余裕がでてきていた SSR or API Hasura + RDSを採用した（採用理由はまた別の機会で） kintoneをそのまま使い続けるのは厳しい問題 React logo©React(Licensed under CC BY 4.0)https://creativecommons.org/licenses/by/4.0/ Copyright©2018 Hasura(Released under the MIT license)https://opensource.org/licenses/mit-license.php
25. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 25 現在のアーキテクチャ（v2.0） Copyright©2018 Hasura(Released under the MIT license)https://opensource.org/licenses/mit-license.php
26. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 26 まとめ ➢ 私が所属する内製開発組織ではエンジニアが少ないという制約の中、成果を出す必要があった ➢ 少人数で開発・運用・保守できることを重視して技術選定を行った ➢ チームメンバーのスキルセットを加味して採用技術を決定した ➢ Next.js、TypeScript ➢ SaaS、PaaS、FaaSを採用し、運用・保守作業が少なくなるような構成にした ➢ 技術を絞ることで、自分たちが重要としているコアなドメイン（業務ロジック）の実装に集中でき、 プロダクトのリリースができた ➢ SaaSの使用は制約を伴うが、要件、自分たちの知識レベルに合わせて選定し続けることで、 継続的に成果が出しつづけられる
27. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 27 宣伝 三菱重工業のDPI部では積極採用中です！ 「私たちの取り組みに興味ある！」「私たちと一緒に働いてみたい！」と思われた方は 「Findy 三菱重工」で検索！ https://findy-code.io/companies/501
29. © MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 29 Vercel, the Vercel design, Next.js and related marks, designs and logos are trademarks or registered trademarks of Vercel, Inc. or its affiliates in the US and other countries.