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

by モンゴル (mongolyy)

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 8 大企業の内製開発組織での難しさ ➢ エンジニアが少ない ➢ エンジニアのバックグラウンドが異なる • 3人 • Scalaエンジニア • C#エンジニア • JavaScriptエンジニア内製開発組織ゆえの難しさ大企業ゆえの難しさ ➢ 複雑な業務フロー、業務ロジック • 複雑な料金計算ロジック、検索、権限制御 ➢ 基幹システムとの連携 • ERPと相互にデータ連携する必要がある制約がある中、実績、成果を出すことが求められる

Slide 9

Slide 9 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 9 大企業の内製開発組織での難しさに対してどう考える？ ➢ エンジニアが少ない ➢ エンジニアのバックグラウンドが異なる • 3人 • Scalaエンジニア • C#エンジニア • JavaScriptエンジニア内製開発組織ゆえの難しさ大企業ゆえの難しさ ➢ 複雑な業務フロー、業務ロジック • 複雑な料金計算ロジック、検索、権限制御 ➢ 基幹システムとの連携 • ERPと相互にデータ連携する必要があるなんとかなりそう少人数で開発・運用・保守できることをまず考えた

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 11 それまでの自分たちの手札を並べて考えてみる ➢ ノーコード、ローコードツール ➢ 複雑な料金計算ロジック、検索、権限制御の実現が難しく、要件が満たせない可能性があった ➢ SPA （Vue.js） + バックエンド（Python） ➢ 該当の言語、ライブラリに精通しているメンバーがおらず、リスクになる可能性があった ➢ サーバーサイドとフロントエンドで異なる言語を使用する場合、学習コストが大きい当時（2021/1）の部内での技術スタック自分自身の手札 ➢ Scala + Play Framework もしくは Ruby on Railsで作る ➢ 他2名がC#、JSのエンジニアであることを考えると、学習コストが大きいと判断

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 13 Headless Commerceとの出会い DB 管理画面 API Headless Commerce フロントエンドクライアント ✓ フロントエンドは使い勝手に直結するので、実装する必要がある ✓ バックエンドはSaaSを使用することで、実装を薄くできる（SaaS）（スクラッチ）

Slide 14

Slide 14 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 14 SaaSをバックエンドにしてみることを考えてみる ➢ 実装するのはフロントエンドのみ ➢ フロントエンドの技術に精通すればいいので学習コストは減る ➢ TypeScriptはJava, C#とも書き方が近かったので、メンバーの中でReact + TypeScript採用でスムーズに開発が開始できそうな感覚があった ➢ SaaSの使用 ➢ 基幹システムとSaaS（kintone）で連携実績があった 3つの課題が解決できるのでは？ ➢ エンジニアが少ない ➢ エンジニアのバックグラウンドが異なる ➢ 複雑な業務フロー、業務ロジック ➢ 基幹システムとの連携

Slide 15

Slide 15 text

© 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を目標としていた要件と照らし合した結果、問題ないことが確認できた

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 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/

Slide 18

Slide 18 text

© 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パターン）

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 20 周辺モジュールのサービス選定少人数で開発・運用・保守するために、積極的にSaaS、FaaSを採用 ➢ auth0 ➢ 認証基盤として部内で使用実績があったため採用 ➢ SendGrid ➢ 他のメール配信SaaSと比較し、自分たちの想定する使い方において、APIが一番使いやすかったため採用 ➢ algolia ➢ kintoneの検索機能が要件を一部満たせなかったため検索SaaSを検討 ➢ 他の検索SaaSと比較し、自分たちの想定する使い方において、APIが一番使いやすかったため採用 ➢ Lambda ➢ SaaS単体だけでは要件を満たせない場合 (algoliaの検索インデックス構築や定期的なメール配信といったバッチ処理)に、Lambdaを使用した

Slide 21

Slide 21 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 21 どうだった？ ➢ 認証機能を1日でローカルで動かせるようにし、1週間で本番環境で使えるようにできた auth0 ➢ メール送信機能を1日で組み込めた ➢ メール開封率が確認できるようになっており、使用状況の把握が簡単にできた SendGrid ➢ 検索ワードが簡単に確認できるようになっており、使用状況の把握が簡単にできた ➢ レスポンスが爆速だった（数十ms～数百ms） ➢ 部分一致検索などRDBと勝手が違うところがあり、調査、検討が必要であった algolia ➢ アプリケーションと同様の言語であるTypeScript、JavaScriptを使用して実装。 Lambda、SAMのキャッチアップだけで開発できたので、学習コストが小さかった。 Lambda ➢ 帳票SaaSの採用も検討したが、見積書のフォーマットに関する要件が厳しく断念その他

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© MITSUBISHI HEAVY INDUSTRIES, LTD. All Rights Reserved. 26 まとめ ➢ 私が所属する内製開発組織ではエンジニアが少ないという制約の中、成果を出す必要があった ➢ 少人数で開発・運用・保守できることを重視して技術選定を行った ➢ チームメンバーのスキルセットを加味して採用技術を決定した ➢ Next.js、TypeScript ➢ SaaS、PaaS、FaaSを採用し、運用・保守作業が少なくなるような構成にした ➢ 技術を絞ることで、自分たちが重要としているコアなドメイン（業務ロジック）の実装に集中でき、プロダクトのリリースができた ➢ SaaSの使用は制約を伴うが、要件、自分たちの知識レベルに合わせて選定し続けることで、継続的に成果が出しつづけられる

Slide 27

Slide 27 text

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

© 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.