Upgrade to Pro — share decks privately, control downloads, hide ads and more …

140年の歴史あるエンタープライズ企業の内製化×マイクロサービス化への航海

 140年の歴史あるエンタープライズ企業の内製化×マイクロサービス化への航海

アーキテクチャConference 2024 にて登壇した際の資料です。

Yusuke Sugiyama

November 26, 2024
Tweet

More Decks by Yusuke Sugiyama

Other Decks in Technology

Transcript

  1. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 2024年11月26日 東京ガス株式会社

    杉山祐介 140年の歴史あるエンタープライズ企業の内製化 × マイクロサービス化への航海
  2. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 自己紹介 @yus_sugiyama

    ❑名前 杉山祐介 / Yusuke Sugiyama ❑所属 東京ガス株式会社リビング戦略部 エンジニアリングマネージャー兼SRE ❑経歴 SI -> 内製 -> AWS(SA) -> 2022年10月より現職 ❑好き Suicaのペンギン / Fashion 2
  3. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. アジェンダ 1.

    東京ガスについて 2. 東京ガス内製開発チームとは 3. 東京ガス内製開発チーム発足の背景 4. マイクロサービス化への航海 a. なぜマイクロサービス化を決めたのか b. 現在の構成と技術選定理由 5. 技術選定をふりかえる a. 学びと反省点 6. まとめ 3
  4. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 本日お話しすること •

    JTC の内製開発チームがどんなチャレンジをしているか。 • レガシーと向き合ってアーキテクチャを決めるまで。 • 最初のマイクロサービスはどうだったのか? 4 旅立とう!
  5. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 会社紹介 会社名

    創立 従業員数 売上高(連結) 主な事業 東京ガス株式会社 明治18年(1885)年10月1日 単体:3,190名 連結:15,504名(2024年3月31日現在) 26,645億円(2024年3月末時点) エネルギー(ガス+電気)ソリューション、海外、都市ビジネス(不動産)など エネルギー需要の増大に伴い、クリーンで高効率なエネルギーとして、 1969年、日本で初めて LNG (液化天然ガス) を導入。 お客さまアカウント数は約1,300万件(*1) 都市ガス国内販売シェア約34%は国内No.1。 小売電力販売件数も387.1件(*2) に到達、新電力No.1となっています。 6 *1 ガス・電気・サービス延べ契約数 2024年3月末時点 *2 2024年3月末時点
  6. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 東京ガス内製開発チームとは 東京ガスCX推進部デジタルマーケティンググループ(2022年当時)に発足した

    自社プロダクトを開発するチームです。 主に myTOKYOGAS と呼ばれる会員サイトの内製開発を行っています。 お客さま 内製開発チーム領域 バックエンド 基幹システム BFF myTOKYOGAS 8
  7. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS とは

    myTOKYOGAS は毎月のガスや電気の使用量・料金を確認できる 登録無料の会員サービスです。 ガス・電気を契約する多くの方にご利用いただいております。 9
  8. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. ちなみに myTOKYOGAS

    は 2023年11月にリニューアルオープンしました! 内製開発チームが担当するフロントエンドはフルリプレイス Next.js React NestJS GraphQL Redis Mongo 10
  9. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. ちなみに myTOKYOGAS

    は 2023年11月にリニューアルオープンしました! 内製開発チームが担当するフロントエンドはフルリプレイス しかしこのアーキテクチャは決して満足いくものではなかった・・・ 後半に続く・・・ 11
  10. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. エネルギー小売全面自由化による変化 2016年4月に電力、2017年4月に都市ガスが小売全面自由化となり、家庭用の分野においても、

    エネルギー会社はお客さまから選ばれる存在になりました。 その結果、デジタル接点によるお客さまの獲得・お客さま体験の向上が急務となっています。 2000年3月 電力小売自由化スタート 【特別高圧】 大規模工場・大規模オフィスビル 電力 都市 ガス 1995年3月 都市ガス小売自由化スタート 【年間200万m3以上】 2004年4月/2005年4月 自由化領域拡大 【高圧】 中小規模工場・中小ビル 1999年11月~2007年4月 自由化領域拡大 【年間10万m3以上】 2016年4月 全面自由化 【低圧】 2017年4月 全面自由化 【年間10万m3以上】 一般家庭など 13
  11. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. なぜマイクロサービス化を決めたのか myTOKYOGAS

    は 2023年11月にリニューアルオープンしました! 内製開発チームが担当するフロントエンドはフルリプレイス バックエンドは・・・? 16
  12. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 現在の myTOKYOGAS

    BFF Database WEB Mobile バックエンド 基幹システム 組織の境界線 関連システム 30 - 40 ...? 東京ガス 内製開発チーム 東京ガス アイネット フルリニューアル リフト&シフト 17
  13. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    例:契約を追加したいケース 1. 現在の会員情報を取得 (API0101, API0110 を呼び出す) 2. 契約情報を追加 (API0204 を呼び出す) 3. 会員基本情報を変更 (API0035 を呼び出す) 4. 個人別契約情報を更新 (API0011 を呼び出す) バックエンド BFF 1. API0101, API0110 2. API0204 3. API0035 4. API0011 手続き発生… 契約とは… 18
  14. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    Fat BFF ドメイン層 契約 ポイント 会員 ・ ・ ・ For WEB xっっっx 契約追加 createOne 契約を追加する 契約を追加する 料金 プロセス層(UI) ・ ・ ・ 契約を追加する For Mobile App ・ ・ ・ ・ ・ ・ For External SVC 契約追加 createOne BFFで吸収: Fat BFFへ コード内部での分離へ WEB Mobile 19
  15. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    Fat BFF ドメイン層 契約 ポイント 会員 ・ ・ ・ For WEB xっっっx 契約追加 createOne 契約を追加する 契約を追加する 料金 プロセス層(UI) ・ ・ ・ 契約を追加する For Mobile App ・ ・ ・ ・ ・ ・ For External SVC 契約追加 createOne 2023年11月リリースが MUST・・・ リニューアル時点では これが限界だった BFFで吸収: Fat BFFへ コード内部での分離へ WEB Mobile 20
  16. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    Fat BFF ドメイン層 契約 ポイント 会員 ・ ・ ・ For WEB xっっっx 契約追加 createOne 契約を追加する 契約を追加する 料金 プロセス層(UI) ・ ・ ・ 契約を追加する For Mobile App ・ ・ ・ ・ ・ ・ For External SVC 契約追加 createOne Web向けに 契約修正しよう WEB Mobile 21
  17. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    Fat BFF ドメイン層 契約 ポイント 会員 ・ ・ ・ For WEB xっっっx 契約追加 createOne 契約を追加する 契約を追加する 料金 プロセス層(UI) ・ ・ ・ 契約を追加する For Mobile App ・ ・ ・ ・ ・ ・ For External SVC 契約追加 createOne Web向けに 契約修正しよう なんか動き 変わったよ!? WEB Mobile 22
  18. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    Fat BFF ドメイン層 契約 ポイント 会員 ・ ・ ・ For WEB xっっっx 契約追加 createOne 契約を追加する 契約を追加する 料金 プロセス層(UI) ・ ・ ・ 契約を追加する For Mobile App ・ ・ ・ ・ ・ ・ For External SVC 契約追加 createOne 急いで外部向けに 修正し直そう WEB Mobile 23
  19. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. myTOKYOGAS の課題

    Fat BFF ドメイン層 契約 ポイント 会員 ・ ・ ・ For WEB xっっっx 契約追加 createOne 契約を追加する 契約を追加する 料金 プロセス層(UI) ・ ・ ・ 契約を追加する For Mobile App ・ ・ ・ ・ ・ ・ For External SVC 契約追加 createOne 急いで外部向けに 修正し直そう モバイルが 動かないのですが WEB Mobile 24
  20. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. モノリスを乗り越えてマイクロサービスへ WEB

    Mobile ドメイン層 契約 ポイント 会員 ・ ・ ・ 契約追加 createOne 契約を追加する 料金 ・ ・ ・ BFF for WEB External 契約を追加する ・ ・ ・ BFF for Mobile 契約を追加する ・ ・ ・ BFF for External マイクロサービス (一例です) 契約追加 createOne 関連システム群 ドメイン層を 分離・整理して バックエンド再構築 変化に強くお客さまに 素早く価値を届けられる アーキテクチャへ 27
  21. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. モノリスを乗り越えてマイクロサービスへ WEB

    Mobile ドメイン層 契約 ポイント 会員 ・ ・ ・ 契約追加 createOne 契約を追加する 料金 ・ ・ ・ BFF for WEB External 契約を追加する ・ ・ ・ BFF for Mobile 契約を追加する ・ ・ ・ BFF for External マイクロサービス (一例です) 契約追加 createOne 関連システム群 変化に強くお客さまに 素早く価値を届けられる アーキテクチャへ マイクロサービス化も手段でしかない 理想論だけでなく事業への貢献を果たす 28 ドメイン層を 分離・整理して バックエンド再構築
  22. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. チームとスキルを見たとき ドメインの深い理解はあるか

    それを実装することはできるか 実装したコードを動かすプラットフォームは用意できるか = 成し遂げる Capability があるか 31
  23. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. チームとスキルを見たとき ドメインの深い理解はあるか

    ✓ 事業部内の内製開発チーム x Biz x 既存システムの知識保有者 それを実装することはできるか ✓ 自ら手を動かすアプリケーションエンジニアの存在 実装したコードを動かすプラットフォームは用意できるか ✓ AWS x コンテナオーケストレーション = OK!! = 成し遂げる Capability があるか ✓ 当チームの Capability で実現可能と判断!!!!! 32
  24. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. チームとスキルを見たとき ドメインの深い理解はあるか

    ✓ 事業部内の内製開発チーム x Biz x 既存システムの知識保有者 それを実装することはできるか ✓ 自ら手を動かすアプリケーションエンジニアの存在 実装したコードを動かすプラットフォームは用意できるか ✓ AWS x コンテナオーケストレーション = OK!! = 成し遂げる Capability があるか ✓ 当チームの Capability で実現可能と判断!!!!! 成し遂げるための高いモチベーションはあるか→溢れている! 33
  25. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 事業部内に発足したからこそ求められるもの 成果を求められる事業部内に所属している以上、

    延々とリアーキテクチャし続けているわけにはいかない。 ※ここからの進め方は組織構造や背景などによって大きく変わる。 あくまでも当社の場合という前提。 距離感の近さは 事業理解に大きなメリット しかし当然 直近成果も求められる 35
  26. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. そして航海へ・・・ マイクロサービス化による課題解決をするための

    Capability は 十分にあると判断・・・長い航海への旅立ちを決意!しかし・・・ 36
  27. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. そして航海へ・・・ マイクロサービス化による課題解決をするための

    Capability は 十分にあると判断・・・長い航海への旅立ちを決意!しかし・・・ 前述のとおり結果も必要 さらに何が待っているか未知… なのでベイビーステップで 37
  28. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. マイクロサービス化における全体構成 AWS

    Cloud VPC Istio-Ingress Gateway Virtual Service EKS Karpenter TGW DX Route 53 ACM GitHub Actions Developers Argo CD(UI) manifest repo TiDB (dedicated) Datadog App/IaC repo ※主要サービスのみ記載 39
  29. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why Kubernetes?

    クラウドネイティブ関連の深堀りは別の機会に! 比較したのは AWS の ECS と EKS. 決め手は「自分たちでどこまで技術選定をコントロールできるか」 CNCF がリードするようなベンダーニュートラルなエコシステムを使いたい。 なので Kubernetes をやっていくことを決意。 Cloud Native Definition Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor- neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. https://www.cncf.io/about/who-we-are/ https://github.com/cncf/toc/blob/main/DEFINITION.md 41
  30. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why TiDB?

    最適なアーキテクチャは チームとスキルを 見て決めよう 43
  31. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why TiDB?

    最適なアーキテクチャは チームとスキルを ←見て決めよう…? 経験者いる…? ベンダーニュートラル…? 44
  32. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why TiDB?

    ここは最後まで悩んだ選定箇所。今回の機能要件は… - 初回1,000万件近いレコードが必要になる(かも) - さらに年間1,000万件の増加。場合によっては2,000万件の年も。 - 新たなプロダクトが誕生するたび、さらに増加。 - 2プロダクトで年間2,000万件増加・・・ - 履歴も保持するため、すぐに億超えの可能性。 - イベントによる Writer へのスパイクが発生。 - Reader 追加だけではしのげない。 - そのためにクラスター追加は避けたい。 ベイビーステップ…? 45
  33. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why TiDB?

    ここは最後まで悩んだ選定箇所。今回の機能要件は… - 初回1,000万件近いレコードが必要になる(かも) - さらに年間1,000万件の増加。場合によっては2,000万件の年も。 - 新たなプロダクトが誕生するたび、さらに増加。 - 2プロダクトで年間2,000万件増加・・・ - 履歴も保持するため、すぐに億超えの可能性。 - イベントによる Writer へのスパイクが発生。 - Reader 追加だけではしのげない。 - そのためにクラスター追加は避けたい。 NewSQL で解決できないか…? 46
  34. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why TiDB?

    ここは最後まで悩んだ選定箇所。今回の機能要件は… - 初回1,000万件近いレコードが必要になる(かも) - さらに年間1,000万件の増加。場合によっては2,000万件の年も。 - 新たなプロダクトが誕生するたび、さらに増加。 - 2プロダクトで年間2,000万件増加・・・ - 履歴も保持するため、すぐに億超えの可能性。 - イベントによる Writer へのスパイクが発生。 - Reader 追加だけではしのげない。 - そのためにクラスター追加は避けたい。 NewSQL で解決できないか…? 47
  35. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. Why TiDB?

    TiDB Cloud の特性 - MySQL 互換(現在 MySQL 5.7 / 8.0 に対応) - 分散DBによる圧倒的なスケーラビリティ。 - 強力な一貫性 - ACID トランザクションを維持。 - ゼロダウンタイムの実現。計画停止からの開放。 - 99.99% の高可用性。 - AWS / Google Cloud などのプラットフォームで提供。 48 https://pingcap.co.jp/tidb-self-managed/ 当チームにとって決め手となったものをピックアップ。 チームにマッチ 課題を解決できそう!
  36. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 結果から:負荷試験はどうだったか 目標の数値は以下のとおり(APIのみ、バッチは別指標にて実施)

    - ピーク時:263rps* x 5minutes(中央値からピーク時数値を策定) - 通常時 :36rps x 5minites - 瞬間最大:526rps x 10seconds ※テーブル件数:1000万件 ※履歴テーブル:3億件 プラスアルファで以下も実施 - ロングラン:正常レスポンス99.999%以上 51 合格条件 API : p(95) < 1s ※API 単体での負荷試験のみ取り扱います。 アプリケーション全体の負荷試験は割愛。 *正確には GET/POST それぞれ 263 rps で同時に実施。
  37. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 結果から:負荷試験はどうだったか 目標の数値は以下のとおり(APIのみ、バッチは別指標にて実施)

    - ピーク時:263rps x 5minutes(中央値からピーク時数値を策定) - 通常時 :36rps x 5minites - 瞬間最大:526rps x 10seconds ※テーブル件数:1000万件 ※履歴テーブル:3億件 プラスアルファで以下も実施 - ロングラン:正常レスポンス99.999%以上 52 ピーク時:263rps x 5minutes(中央値からピーク時数値を策定) ピックアップ ※API 単体での負荷試験のみ取り扱います。 アプリケーション全体の負荷試験は割愛。
  38. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 結果から:負荷試験はどうだったか 参考:ピーク時(263rps

    x 5minutes) の k6 ダッシュボード 53 ※実施時のイメージとなります。 繰り返し実行しているため以降の画像と整合しない場合があります。
  39. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 結果から:負荷試験はどうだったか 参考:ピーク時(263rps

    x 5minutes) の API サマリー 54 Istio Ingress Gateway メトリクス (受け付けたリクエスト数) アプリケーションレスポンス ※実施時のイメージとなります。 繰り返し実行しているため画像同士が整合しない場合があります。
  40. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 結果から:負荷試験はどうだったか 参考:瞬間最大(526rps

    x 10seconds) 55 ※実施時のイメージとなります。 繰り返し実行しているため画像同士が整合しない場合があります。
  41. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 結果から:負荷試験はどうだったか 負荷試験中にも当然問題発生・・・チューニング実施。

    結果として GET, POST ともにピーク時・瞬間最大時をクリア。 最終的な App/TiDB の基本スペックは以下のとおり。 - App Pod:6 Pod 0.25core/256MiB(istio-proxy も同様/バッチは除く) - QoS : Guaranteed - Istio ingress gateway:6 Pod 0.1core/128MiB - TiDB:8 vCPU, 32 GiB / 2 Nodes - TiKV:8 vCPU, 32 GiB / 200GiB Storage x 3 Nodes 56
  42. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. クラウドネイティブとの乖離 Kubernetes

    側の Istio ingress gateway スケールインにて リクエスト落ちが頻発。実施期間内に根本原因の修正に至れず。 58 スケールインは難しい 運用で継続改善予定 ※深堀りは別の機会に… Istio ingress gateway はトラフィックをさばける固定 6 Pod に。 スケーラビリティとは一体・・・
  43. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. クラウドネイティブとの乖離 TiDB

    クラスター dedicated にオートスケールの仕組みがない。 頻繁にスケールイン・スケールアウトをコンソールから実施すべきか? 59 結果として最大負荷をさばけるスペックと Node 数に。 また今回のアプリケーション特性として TiFlash は活用せず・・・
  44. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. よかったこと:TiDB -

    ローカルでの開発環境は tiup が便利。 - 開発観点で非常に重要。Golang では ORM も利用可能。 - クラスター単体でもライターが分散される。 - 負荷試験の結果を見るに Aurora だったら巨大インスタンスか複数クラスターが必要だっ たかもしれない。 - DB同士での比較をした際にコストメリットが得られたかは検証不足。 - オートスケールがほしい・・・が、TCO としての効果はあったはず。 - DB 特化のエンジニアを獲得できない小規模チームではアプリ・SRE全体での恩恵あり。 - アプリとSREとの協業はMUST。常時張り付いていた。 - メンテナンスによるダウンタイムゼロの実現。 - 計画停止からの開放。オンラインスケールアップは有事の際に安心できる。 - とはいえ頻繁に実施する負荷も鑑みて判断したい。(前述の通り当チームは固定した) ★決してインフラ観点でメンテナンスフリーだから、という基準だけで選定するのはNG 60
  45. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 知っておくべきだったこと:TiDB -

    外部キー制約:共有ロックではない。 - auto increment の仕組み。 - MySQL 完全互換ではない。 - コネクションプールの connection time 管理。 - クラスター作成時にバージョンが自動で決まる。 61
  46. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 知っておくべきだったこと:TiDB -

    外部キー制約:共有ロックではない。 - auto increment の仕組み。 - MySQL 完全互換ではない。 - コネクションプールの connection time 管理。 - クラスター作成時にバージョンが自動で決まる。 62 外部キー制約:共有ロックではない。
  47. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 知っておくべきだったこと:TiDB 63

    外部キー制約:共有ロックではない。 Table : transaction record : 1 record : 2 record : 3 record : 4 record : 5 . . . record : n Table : master record : ver1
  48. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 知っておくべきだったこと:TiDB 64

    外部キー制約:共有ロックではない。 Table : transaction record : 1 record : 2 record : 3 record : 4 record : 5 . . . record : n Table : master record : ver1 更新処理中に 見事な待ち行列が発生 36rps でエラー連発
  49. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 知っておくべきだったこと:TiDB 65

    解決策として局所的に外部キー制約を外してアプリケーション側で担保。 Table : transaction record : 1 record : 2 record : 3 record : 4 record : 5 . . . record : n Table : master record : ver1 グローバルに外部キー制約を除去した わけではなく、セッションごとに必要 となる処理の前段で解除→処理が終わ ったら再度有効化している。 これにより 36rps 突破 以降の負荷試験も突破
  50. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 知っておくべきだったこと:TiDB 66

    解決策として局所的に外部キー制約を外してアプリケーション側で担保。 Table : transaction record : 1 record : 2 record : 3 record : 4 record : 5 . . . record : n Table : master record : ver1 TiDB公式ドキュメントにも以下の記載がある。 https://docs.pingcap.com/ja/tidb/stable/foreign-key TiDB は現在LOCK IN SHARE MODEサポートしていないため、子 テーブルが大量の同時書き込みを受け入れ、参照される外部キー値 のほとんどが同じである場合、深刻なロック競合が発生する可能性 があります。大量の子テーブルデータを書き込む場合は foreign_key_checks無効にすることをお勧めします。
  51. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 次に向けて 68

    前述の外部キー制約の件などもあったが、MySQL と高い互換性をもって ORM を利用して開発できるのは、チームにとって大きなメリットだった。 また、増加するデータに対してスケーラビリティの問題から解放されるという 点も、事業価値を追求する内製開発チームにとって大きなメリット。 今後は ACID 特性のある NewSQL としての特徴を活かし さらに深堀りして他サービスにも展開していきたい! (ポイントサービスなど・・・
  52. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. VPC 今回よかったこと

    事前に k6 Operator を Kubernetes 上に用意したことで繰り返し実行を容易に。 69 EKS Istio-Ingress Gateway Virtual Service EKS Karpenter Developers Argo CD(UI) k6 operator k6 operator は 分散実行も可能 Datadog 結果はDatadogで確認
  53. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 本日お話ししたこと •

    JTC の内製開発チームがどんなチャレンジをしているか。 • レガシーと向き合ってアーキテクチャを決めるまで。 • 最初のマイクロサービスはどうだったのか? 71 旅立った!
  54. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. これまでとこれからと 140年の歴史ある東京ガスに発足した内製開発チームは

    マイクロサービス化への航海に旅立ちました。 そして最初のサービスは順風満帆・・・(多分) 私たちはチーム(人)とスキルを見てアーキテクチャを決めています。 そして同時に「ソフトウェアエンジニアとしてチャレンジングであるか」 という観点も重要視しています。(事業貢献とスキル向上のバランスが大事) 当社の価値観でもある「挑み続ける」を体現すべく、 これからも新たなチャレンジをし続けていきます! 72
  55. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. チームをどう組むか・維持するか コンウェイの法則は非常に有名。

    JTCでの戦いは、まさにこれの連続・・・待ち受ける個別最適化の嵐。 しかし裏を返せば、適切なアーキテクチャを設計できるソフトウェアエンジニアが プロパーとともに組織構成も変えてしまうことで、会社が真のポテンシャルを発揮できるのでは? 現マネージャー及川 (東京ガス生え抜き人材) 一緒に考えましょう! はい、よろこんで! 杉山 74
  56. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. トップダウン? or

    ボトムアップ? 正解はないと思いますが、我々は現場課題から進めた結果、今があります。 しかし、このうねりをどうやって広げていくのか、悩む日々です。 これは次の大きなミッションだと考えています! 現マネージャー及川 (東京ガス生え抜き人材) 課題をクリアする!! はい、よろこんで! 杉山 75
  57. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. 余談:会議の連続? 「会議ばかりなのでは」という話。

    スクラムをガッツリやってるチームは事実としてイベントが多いが「会議」ではない。 また、Biz との対話は必要なので定例があるのも事実。 でも内部で調整可能な事業会社は個人的に気が楽ではある。 現マネージャー及川 (東京ガス生え抜き人材) これは出ないでいいよ はい、よろこんで! 杉山 76
  58. Copyright©︎ TOKYO GAS Co., Ltd. All Rights Reserved. We are

    hiring!! あなたもぜひ、この船に乗りませんか? 77 GoGo!! 東京ガス 内製開発 で検索!