クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achieving BizDevOps in in-house development of cloud-native energy-saving services

Transcript

1. 北海道ガス株式会社 小笠原 元気 クラウドネイティブな省エネサービスの 内製開発で、BizDevOpsを実現する 1 2024.6.15 CloudNative Days Summer 2024
2. ⾃⼰紹介 Genki （⼩笠原 元気） 北海道ガス株式会社（2017〜） ・Job, Role フロントエンド・バックエンドエンジニア 開発チームのテックリード 趣味︓旅⾏・筋トレ CloudNative Days 歴︓4年（2020初参加） 最近興味があること︓Next.js, Vercel @geivk 2
3. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 Future works・まとめ 3
4. 今⽇のお話の内容 • クラウドネイティブで組織や事業の課題を解決した話 • 事業会社・事業部⾨だからこそ感じたクラウドやクラウドネイティブの良さ • 初⼼者スタートでも熱量とコミュニティで乗り切った話 4
5. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ 5
6. 北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給業 ガス機器販売 851名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,738億円（連結） 2024年3⽉末時点 お客さま 件数 ガス︓604,329件 電⼒︓254,956件 会社概要 6
7. 業務⽤省エネサービス「Mys3（ミース）」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢（少機能・低価格）が少ない。 Make your smart solution service Mys（ミース）: スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7
8. 「Mys3（ミース）」i-Ch / REM 常時計測・監視、 ⾃動で省エネ制御 セントラル空調機器 当社クラウドシステム 冷温⽔（往） 冷温⽔（還） アタッチメント型 制御ユニットを設置 計測データの⾒える化 遠隔制御 吸収式冷温⽔機遠隔省エネサービス 当社クラウドシステム 計測データの⾒える化 CO2/温度/湿度 データ CO2・温湿度可視化サービス
9. Mys3の技術スタック • パブリッククラウド︓Amazon Web Services (AWS) • 通信 ︓SORACOM • インフラ ︓AWS IoT, AWS Lambda, Amazon ECS • バックエンド ︓Python (AWS SDK) • フロントエンド ︓React.js • 可視化画⾯ ︓Grafana（on Amazon ECS） • DevTools ︓AWS CDK, Amazon CodeCatalyst 9
10. Mys3の技術スタック • パブリッククラウド︓Amazon Web Services (AWS) • 通信 ︓SORACOM • インフラ ︓AWS IoT, AWS Lambda, Amazon ECS • バックエンド ︓Python (AWS SDK) • フロントエンド ︓React.js • 可視化画⾯ ︓Grafana（on Amazon ECS） • DevTools ︓AWS CDK, Amazon CodeCatalyst 主にAWSを中⼼に利⽤ → できるだけ⼀般的な名称でお話しします 10
11. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ 11
12. CNCF Cloud Native Definition v1.1 • Cloud Native Computing Foundation(CNCF) スケーラブルなアプリケーションの構築と実⾏するための能⼒ → 回復⼒・管理⼒・可観測性・疎結合アーキテクチャシステム ⾃動化 イミュータブル インフラストラクチャ 宣⾔的API コンテナ サービスメッシュ マイクロサービス 12
13. CNCF Cloud Native Definition v1.1 • Cloud Native Computing Foundation(CNCF) スケーラブルなアプリケーションの構築と実⾏するための能⼒ → 回復⼒・管理⼒・可観測性・疎結合アーキテクチャシステム ⾃動化 イミュータブル インフラストラクチャ 宣⾔的API コンテナ サービスメッシュ マイクロサービス インパクトのある変更を最⼩限の労⼒で 頻繁に実⾏することが可能になる 13
14. Cloud Native glossary • クラウドネイティブアプリケーションは、クラウドアーキテクチャと容易に 統合でき、クラウドのリソースとスケーリング機能を活⽤できます。 • クラウドネイティブアプリケーションは弾⼒性があり、管理しやすく、それ に付随する⼀連のクラウドサービスによって⽀援されます。 さまざまなクラ ウドサービスによって、⾼度なオブザーバビリティが有効になり、ユーザー は問題が深刻化する前に発⾒して対処することができます。 堅牢な⾃動化と 組み合わせることで、エンジニアは最⼩限の労⼒で、インパクトの⼤きい変 更を頻繁にかつ予想通りに⾏うことができます。 https://glossary.cncf.io/ja/ より引⽤ 14
15. クラウドネイティブで私たちは何が得られるのか︖ クラウドネイティブアプリケーションによる価値 新しいサービス・付加価値の 創出に注⼒できる お客さまに提供できる サービスの幅が広がる DX(Developer eXperience) 開発者体験の向上 15
16. Bizチーム・Devチーム・Opsチーム Biz, Dev, Ops チームがそれぞれのKPI を持っている状態 • 関⼼事は⾃チームの最⼤化 • 事業部⾨で初期から別々の組織で 進めていくのはかなりのハードル 予算・リソース・能⼒全てが不⾜ Biz Dev Ops 16
17. BizDevOps Biz, Dev, Ops チームが共通の KPI を持っ ている状態＝密な連携 • 関⼼事は共通になっている • お互いにそれぞれを理解している • ⾼速に概念検証を繰り返す • 継続的なサービスリリース / 改善 → 特に事業部⾨では BizDevOps が必要 Biz Dev Ops 17
18. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ
19. Mys3 の構想の当初 19 低価格 最⼩機能(MVP) ⼤規模⼯事不要 ⾃動化 IoT クラウド 通信 プログラミング 市場 ニーズ 技術 シーズ ✔ ✔ ✔ ✔ ? ? ? ? ニーズはあったが、技術がなかった ＝Dev, Ops について知識がなかった
20. 従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 当社の従来のシステム開発の課題 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万 オーダーの発注 20 IoT クラウド 通信 プログラミング 技術 シーズ ? ? ? ? 多額の初期投資ができない状況＋ 社内ナレッジの取得 ⇒ 内製開発へ
21. 内製開発の始まり 2018年〜 クラウド/IT分野は技術・ビジネス の変化が激しい 2018/7⽉〜 社内有志メンバーで勉強会・ サークルを⽴ち上げ （プログラミングやIoT技術を中⼼に） 技術論者ではなく、技術的な思考と⾏動を 両⽴するスピーディな実践者の集まりが必要 クラウドは 良いですよ︕ それって、 おいしいですか︖ What is Cloud? はじめは「無知状態」 サーバーが何か知らなかった 21
22. 業務⽤ 分野の EMS推進 経営のミッション DX ビ ジ ネ ス サ イ ド 経営課題への 取り組み 内製開発のターニングポイント 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 知的好奇⼼ ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 22
23. しかし、内製開発のスタート時は・・・ エネルギーサービス業務 発電所業務 PdM 開発 ほかの業務と兼業からの スタート（現在も継続中） 23
24. ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 事業部⾨の内製開発が抱える BizDevOps の課題 24
25. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 25
26. ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 事業部⾨の内製開発が抱える BizDevOps の課題
27. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ 27
28. クラウドネイティブのアプローチ ⾃動化 サービスメッシュ イミュータブル インフラストラクチャ コンテナ マイクロ サービス 宣⾔的 API クラウドネイティブのアプローチやクラウドのメリットを 最⼤限利⽤し BizDevOps の課題を解決していった 28
29. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 29
30. 安価かつ⾃由度の⾼いサービスを提供するには︖ • 従来のシステム開発⼿法やデバイスで構築するの難しい ◆ システムの課題解決 • IoTのプラットフォームを作成 • 接続すれば遠隔計測・遠隔制御ができるようにしたい • 従量課⾦制のパブリッククラウドが最適 • 後からニーズに合わせて機能追加したい → マイクロサービス 30
31. 安価かつ⾃由度の⾼いサービスを提供するには︖ • 従来のシステム開発⼿法やデバイスで構築するの難しい ◆ システムの課題解決 • IoTのプラットフォームを作成 • 接続すれば遠隔計測・遠隔制御ができるようにしたい • 従量課⾦制のパブリッククラウドが最適 • 後からニーズに合わせて機能追加したい → マイクロサービス ◆ デバイスの課題解決 • 当初、制御でよく使われる汎⽤のPLCを利⽤ • さらに安価にするためマイコン＋IoTゲートウェイの構成に 31
32. 「やってみた」の恩恵 • 知的好奇⼼をベースとした「やってみた」の実践 • 部署・部⾨を超えて⾃由に報告しあう社内コミュニティの役割 ▪技術習得 プログラミング⾔語 IoT技術 Raspberry Pi ESP32 モノ 通信 クラウド ▪知⾒獲得 機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン すべて独学 学習→熱量→実践→共有→・・・の好循環 32
33. 環境と外部コミュニティ • 「やってみる」の熱量 • 「やってみなさい」の上司のサポート ⼼理的安全性や裁量があったことが重要 • 外部コミュニティへの参加 初⼼者ながら「やってみた」を JAWS FESTA 2019 SAPPORO で発表 コミュニティの熱量を⽣で感じた クラウドの最新事例を常に収集できる 33
34. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 34
35. マイクロサービスとは （イメージ） • 機能を異なるマイクロサービスに分離することにより、それらを独⽴して • デプロイ、アップデート、スケールすることが容易になります。 35 機能 A 機能 B 機能 C 機能 D 機能 A 機能 B 機能 C 機能 D モノリス マイクロサービス https://glossary.cncf.io/ja/ より引⽤
36. PoC のアーキテクチャ ◆ PoC • ほぼ SORACOM 完結したアーキテクチャ • AWS 上にデータレイク＋パイプラインを構築 • デバイスの設定情報は直接 SSH で接続して書き換える （ここまでデータベース構築なし） CloudNative アプローチ マイクロサービス PLC modbus アナログ I/O 制御 信号 ゲートウェイ SORACOM AWS Cloud データ 遠隔操作 可視化 クラウド アダプタ IoT Core データレイク SSH 制御盤 36
37. サービスローンチ時のアーキテクチャ ◆ サービスローンチ仕様 • フロントエンドからデバイスの設定情報を書き換えたい • AWS IoT を使って MQQT(S) の相互通信(Pub/Sub)・即時通信 • API を⽤意しバックエンドで IoT Core へ指令 • ファームウェアの OTA(On The Air)アップデートも実装 CloudNative アプローチ マイクロサービス アナログ I/O 制御 信号 制御盤 SORACOM AWS Cloud IoT Core クラウド転送 サービス 遠隔指令 MQTT REST API 37
38. 宣⾔的 API（イメージ） • ⽬的の状態を定義（設定ファイルのイメージ） • コントローラが⽬的状態と差分をチェックし⽬的の状態へ⾃⼰修復する 38 https://glossary.cncf.io/ja/ より引⽤ 設定情報 コンテナの数︓10 コントローラ
39. サービスローンチ時のアーキテクチャ ◆ サービスローンチ仕様 • 可視化画⾯を SaaS からセルフホストに変更（OSS︓Grafana） • データベースとして時系列DB・Key-Value DBを採⽤ • コンテナオーケストレーションサービスの宣⾔的 API で運⽤の省⼒化 CloudNative アプローチ コンテナ・宣⾔的API AWS IoT Core Amazon Timestream （時系列DB） Amazon DynamoDB （Key-Value DB） Amazon ECS コンテナ オーケストレーション 39
40. アーキテクチャの段階的な変更 • クラウドならではの「リソースの使い捨て」 ワンクリックでリソースを起動、失敗した時にすぐリソースを廃棄できる • アーキテクチャをその段階の最適なものに変えられる PoC→サービスローンチ時 ビッグバンの移⾏ではなく拡張性が必要な箇所から、機能を徐々に移⾏できる CloudNative アプローチ マイクロサービス 40
41. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 41
42. コンテナとは（イメージ） • コンピューターのオペレーティングシステムがリソースと機能⾯で制限を管 理する、実⾏中のプロセス • コンテナイメージとしてパッケージ化されている 42 https://glossary.cncf.io/ja/ より引⽤ ランタイム ライブラリ 設定 コンテナイメージ ビルド コンテナ
43. 開発環境の設定のハードル 事業会社で内製開発をする悩み︓新⼊社員教育でプログラミングがないこと • 初⼼者には環境設定のハードルが⾼い • オンボーディングの場合も周辺ツールが多すぎてハードルが⾼い Python インストール Python を homebrew で… Docker・git ・CDK も… Node.js もお願いします main ブランチから git clone してください 開発にJoin したメンバー （初⼼者） ・・・ PATH 設定 必要です CloudNative アプローチ コンテナ 43
44. 開発環境の設定のハードルの解決 ◆ Amazon CodeCatalyst Dev Environments • 特定のブランチをgit clone した状態で SSH でコンテナに接続 • デフォルトで⼊っているミドルウェア ◦ Docker, Helm, AWS CLI, SAM CLI, CDK CLI ◦ Node.js, Python, Go, Ruby, Java, PHP • Github CodeSpaces も同様の機能 コンテナ＝クラウドネイティブ技術のメリット CloudNative アプローチ コンテナ 44
45. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 45
46. イミュータブルインフラストラクチャ（イメージ） • ⼀度デプロイされると変更することができないインフラストラクチャ ＝インフラは使い捨て、変更があるたびに再構築する 46 https://glossary.cncf.io/ja/ より引⽤ v1 v2 v3 構築 再構築 再構築 機能追加 パッチ Infrastructure as Code
47. Infrastructure as Code: IaC • 当初は、簡単な ETL の関数のみのためコンソールから作成 • API ゲートウェイ＋サーバレスファンクションで構築 • フロントエンドからの要件増 → サーバレスファンクションの数が増⼤ CloudNative アプローチ イミュータブルインフラストラクチャ ETL 遠隔指令 通信確認 設定情報取得 デバイス取得 エラーロガー 設定履歴 データクエリ デバイス認証 ETL etc. 47
48. Infrastructure as Code: IaC • いつ・誰が・どのファンクションを・どのように変更したかわからない • 認知負荷・管理⼯数⼤ → Infrastructure as Code で管理 • Terraform or AWS CDK → IoT リソースに対応している AWS CDK を採⽤ ◆ ⾔語の選定 • 最初は Python で記述していたが型がない • 必須プロパティなども毎回 Document で調べなくてはいけない → 途中から、Python から TypeScript に全⾯移⾏ CloudNative アプローチ イミュータブルインフラストラクチャ 48
49. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更（SaaSからの乗り換え） • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 49
50. IaC の⾃動デプロイ • 当初、３つの環境にそれぞれ⼿動デプロイしていた • 開発者も開発環境に毎回デプロイが必要になっていた • オペレーションミスが発⽣し、特定の⼈がいないとデプロイできない • ビッグバンデプロイになりがちだった dev （開発環境） stage （テスト環境） 開発者 prod （本番環境） デプロイ 職⼈による デプロイ CloudNative アプローチ ⾃動化 50
51. 51 dev （開発環境） stage （テスト環境） 開発者 Repo git push Workflow Repo/ Issue プルリク 作成 Workflow 承認 デプロイ デプロイ prod （本番環境） ⼿動テスト （デバイス） Workflow Repo デプロイ プルリク 作成 承認 Amazon CodeCatalyst テストの⾃動化・デプロイの⾃動パイプラインを構築 CI/CD パイプラインの構築 CloudNative アプローチ ⾃動化・コンテナ
52. テストの重要性 • テスト・・・とは・・・︖ 何から⼿をつけたらいいかわからない状態 継続的インテグレーション / デプロイの⾼頻度デプロイ → 既存の機能が担保されているという意味でテストが重要 ü AWS CDK を TypeScript に移⾏するタイミングでテストを導⼊ ü バックエンドのロジックにもテストを導⼊ • ただし開発⼈員が限られているため、コア機能にテストを集約 CloudNative アプローチ ⾃動化 52
53. Agenda 会社 / プロジェクト（Mys3︓ミース）概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 Future works・まとめ
54. サービスローンチ後の機能追加 • サービスローンチ後も、お客さまからのフィードバックで機能を実装 • 曜⽇別・時間別のスケジュール運転機能 • 気象情報による天気に連動した運転機能 • 他の機器への拡張性・・・etc. デバイスへの実装は、影響が⼤きい クラウドにて素早く・柔軟に実装 ⾼速に実装し検証しながら フィードバックをもらう お客さま 開発チーム （お客さまに近い⽴場） 54
55. FUTURE WORKS ◆ クラウドサービス • CSPM: Sysdig CSPM の利⽤検討（オペレーションコスト低減） • RDB: TiDB Serverless に移⾏できないか検討（コスト低減） 開発当初より多様かつ、さらに安価なサービスが出ている 55
56. FUTURE WORKS ◆ クラウドサービス • CSPM: Sysdig CSPM の利⽤検討（オペレーションコスト低減） • RDB: TiDB Serverless に移⾏できないか検討（コスト低減） 開発当初より多様かつ、さらに安価なサービスが出ている ◆ ⽣成 AI • ⼈数が少ないからこそ、⽣成 AI をフル活⽤したい • ローカル LLM や コード⽣成、Github Copilot Workspace など 進化が著しいため、特定のサービスにとらわれずトライしたい 56
57. まとめ • 内製開発こそ、クラウドネイティブの考えを取り⼊れるべき 事業により注⼒できるようになるメリットが⾮常に⼤きい • 社外コミュニティで熱量を感じ、最新のクラウドネイティブ事例を取り⼊れる 社内のコミュニティでまずは「やってみた」を実践 • クラウドネイティブをすぐに取り⼊れられなくても、知っていることが重要 → 事業化・サービス化のどこかで必要なタイミングが出てくる • クラウドネイティブを取り⼊れたことで BizDevOps を実現できた お客さまのフィードバックから機能実装することができている 57
58. Thank you!