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

クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achiev...

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

Genki Ogasawara

June 14, 2024
Tweet

More Decks by Genki Ogasawara

Other Decks in Technology

Transcript

  1. 北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給業 ガス機器販売

    851名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,738億円(連結) 2024年3⽉末時点 お客さま 件数 ガス︓604,329件 電⼒︓254,956件 会社概要 6
  2. 業務⽤省エネサービス「Mys3(ミース)」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢(少機能・低価格)が少ない。 Make your smart

    solution service Mys(ミース): スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7
  3. 「Mys3(ミース)」i-Ch / REM 常時計測・監視、 ⾃動で省エネ制御 セントラル空調機器 当社クラウドシステム 冷温⽔(往) 冷温⽔(還) アタッチメント型

    制御ユニットを設置 計測データの⾒える化 遠隔制御 吸収式冷温⽔機遠隔省エネサービス 当社クラウドシステム 計測データの⾒える化 CO2/温度/湿度 データ CO2・温湿度可視化サービス
  4. 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
  5. 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
  6. CNCF Cloud Native Definition v1.1 • Cloud Native Computing Foundation(CNCF)

    スケーラブルなアプリケーションの構築と実⾏するための能⼒ → 回復⼒・管理⼒・可観測性・疎結合アーキテクチャシステム ⾃動化 イミュータブル インフラストラクチャ 宣⾔的API コンテナ サービスメッシュ マイクロサービス 12
  7. CNCF Cloud Native Definition v1.1 • Cloud Native Computing Foundation(CNCF)

    スケーラブルなアプリケーションの構築と実⾏するための能⼒ → 回復⼒・管理⼒・可観測性・疎結合アーキテクチャシステム ⾃動化 イミュータブル インフラストラクチャ 宣⾔的API コンテナ サービスメッシュ マイクロサービス インパクトのある変更を最⼩限の労⼒で 頻繁に実⾏することが可能になる 13
  8. Cloud Native glossary • クラウドネイティブアプリケーションは、クラウドアーキテクチャと容易に 統合でき、クラウドのリソースとスケーリング機能を活⽤できます。 • クラウドネイティブアプリケーションは弾⼒性があり、管理しやすく、それ に付随する⼀連のクラウドサービスによって⽀援されます。 さまざまなクラ

    ウドサービスによって、⾼度なオブザーバビリティが有効になり、ユーザー は問題が深刻化する前に発⾒して対処することができます。 堅牢な⾃動化と 組み合わせることで、エンジニアは最⼩限の労⼒で、インパクトの⼤きい変 更を頻繁にかつ予想通りに⾏うことができます。 https://glossary.cncf.io/ja/ より引⽤ 14
  9. BizDevOps Biz, Dev, Ops チームが共通の KPI を持っ ている状態=密な連携 • 関⼼事は共通になっている

    • お互いにそれぞれを理解している • ⾼速に概念検証を繰り返す • 継続的なサービスリリース / 改善 → 特に事業部⾨では BizDevOps が必要 Biz Dev Ops 17
  10. Mys3 の構想の当初 19 低価格 最⼩機能(MVP) ⼤規模⼯事不要 ⾃動化 IoT クラウド 通信

    プログラミング 市場 ニーズ 技術 シーズ ✔ ✔ ✔ ✔ ? ? ? ? ニーズはあったが、技術がなかった =Dev, Ops について知識がなかった
  11. 従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 当社の従来のシステム開発の課題 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万

    オーダーの発注 20 IoT クラウド 通信 プログラミング 技術 シーズ ? ? ? ? 多額の初期投資ができない状況+ 社内ナレッジの取得 ⇒ 内製開発へ
  12. 業務⽤ 分野の EMS推進 経営のミッション DX ビ ジ ネ ス サ

    イ ド 経営課題への 取り組み 内製開発のターニングポイント 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 知的好奇⼼ ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 22
  13. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆

    開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 25
  14. ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え)

    • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 事業部⾨の内製開発が抱える BizDevOps の課題
  15. クラウドネイティブのアプローチ ⾃動化 サービスメッシュ イミュータブル インフラストラクチャ コンテナ マイクロ サービス 宣⾔的 API

    クラウドネイティブのアプローチやクラウドのメリットを 最⼤限利⽤し BizDevOps の課題を解決していった 28
  16. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆

    開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 29
  17. 安価かつ⾃由度の⾼いサービスを提供するには︖ • 従来のシステム開発⼿法やデバイスで構築するの難しい ◆ システムの課題解決 • IoTのプラットフォームを作成 • 接続すれば遠隔計測・遠隔制御ができるようにしたい •

    従量課⾦制のパブリッククラウドが最適 • 後からニーズに合わせて機能追加したい → マイクロサービス ◆ デバイスの課題解決 • 当初、制御でよく使われる汎⽤のPLCを利⽤ • さらに安価にするためマイコン+IoTゲートウェイの構成に 31
  18. 「やってみた」の恩恵 • 知的好奇⼼をベースとした「やってみた」の実践 • 部署・部⾨を超えて⾃由に報告しあう社内コミュニティの役割 ▪技術習得 プログラミング⾔語 IoT技術 Raspberry Pi

    ESP32 モノ 通信 クラウド ▪知⾒獲得 機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン すべて独学 学習→熱量→実践→共有→・・・の好循環 32
  19. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆

    開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 34
  20. PoC のアーキテクチャ ◆ PoC • ほぼ SORACOM 完結したアーキテクチャ • AWS

    上にデータレイク+パイプラインを構築 • デバイスの設定情報は直接 SSH で接続して書き換える (ここまでデータベース構築なし) CloudNative アプローチ マイクロサービス PLC modbus アナログ I/O 制御 信号 ゲートウェイ SORACOM AWS Cloud データ 遠隔操作 可視化 クラウド アダプタ IoT Core データレイク SSH 制御盤 36
  21. サービスローンチ時のアーキテクチャ ◆ サービスローンチ仕様 • フロントエンドからデバイスの設定情報を書き換えたい • 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
  22. サービスローンチ時のアーキテクチャ ◆ サービスローンチ仕様 • 可視化画⾯を SaaS からセルフホストに変更(OSS︓Grafana) • データベースとして時系列DB・Key-Value DBを採⽤

    • コンテナオーケストレーションサービスの宣⾔的 API で運⽤の省⼒化 CloudNative アプローチ コンテナ・宣⾔的API AWS IoT Core Amazon Timestream (時系列DB) Amazon DynamoDB (Key-Value DB) Amazon ECS コンテナ オーケストレーション 39
  23. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆

    開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 41
  24. 開発環境の設定のハードル 事業会社で内製開発をする悩み︓新⼊社員教育でプログラミングがないこと • 初⼼者には環境設定のハードルが⾼い • オンボーディングの場合も周辺ツールが多すぎてハードルが⾼い Python インストール Python を

    homebrew で… Docker・git ・CDK も… Node.js もお願いします main ブランチから git clone してください 開発にJoin したメンバー (初⼼者) ・・・ PATH 設定 必要です CloudNative アプローチ コンテナ 43
  25. 開発環境の設定のハードルの解決 ◆ 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
  26. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆

    開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 45
  27. Infrastructure as Code: IaC • 当初は、簡単な ETL の関数のみのためコンソールから作成 • API

    ゲートウェイ+サーバレスファンクションで構築 • フロントエンドからの要件増 → サーバレスファンクションの数が増⼤ CloudNative アプローチ イミュータブルインフラストラクチャ ETL 遠隔指令 通信確認 設定情報取得 デバイス取得 エラーロガー 設定履歴 データクエリ デバイス認証 ETL etc. 47
  28. Infrastructure as Code: IaC • いつ・誰が・どのファンクションを・どのように変更したかわからない • 認知負荷・管理⼯数⼤ → Infrastructure

    as Code で管理 • Terraform or AWS CDK → IoT リソースに対応している AWS CDK を採⽤ ◆ ⾔語の選定 • 最初は Python で記述していたが型がない • 必須プロパティなども毎回 Document で調べなくてはいけない → 途中から、Python から TypeScript に全⾯移⾏ CloudNative アプローチ イミュータブルインフラストラクチャ 48
  29. 事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆

    開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 49
  30. 51 dev (開発環境) stage (テスト環境) 開発者 Repo git push Workflow

    Repo/ Issue プルリク 作成 Workflow 承認 デプロイ デプロイ prod (本番環境) ⼿動テスト (デバイス) Workflow Repo デプロイ プルリク 作成 承認 Amazon CodeCatalyst テストの⾃動化・デプロイの⾃動パイプラインを構築 CI/CD パイプラインの構築 CloudNative アプローチ ⾃動化・コンテナ
  31. テストの重要性 • テスト・・・とは・・・︖ 何から⼿をつけたらいいかわからない状態 継続的インテグレーション / デプロイの⾼頻度デプロイ → 既存の機能が担保されているという意味でテストが重要 ü

    AWS CDK を TypeScript に移⾏するタイミングでテストを導⼊ ü バックエンドのロジックにもテストを導⼊ • ただし開発⼈員が限られているため、コア機能にテストを集約 CloudNative アプローチ ⾃動化 52
  32. FUTURE WORKS ◆ クラウドサービス • CSPM: Sysdig CSPM の利⽤検討(オペレーションコスト低減) •

    RDB: TiDB Serverless に移⾏できないか検討(コスト低減) 開発当初より多様かつ、さらに安価なサービスが出ている 55
  33. FUTURE WORKS ◆ クラウドサービス • CSPM: Sysdig CSPM の利⽤検討(オペレーションコスト低減) •

    RDB: TiDB Serverless に移⾏できないか検討(コスト低減) 開発当初より多様かつ、さらに安価なサービスが出ている ◆ ⽣成 AI • ⼈数が少ないからこそ、⽣成 AI をフル活⽤したい • ローカル LLM や コード⽣成、Github Copilot Workspace など 進化が著しいため、特定のサービスにとらわれずトライしたい 56