Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achiev...
Search
Genki Ogasawara
June 14, 2024
Technology
2
660
クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achieving BizDevOps in in-house development of cloud-native energy-saving services
Genki Ogasawara
June 14, 2024
Tweet
Share
More Decks by Genki Ogasawara
See All by Genki Ogasawara
クラウドのスケーリングの力で5時間 かかるバッチジョブを10分に短縮する / Reduce the batch job time by a 36th using the power of scaling in the public cloud
genkiogasawara
1
8
IT知識ゼロからのスタートで、 事業部における内製開発をどうやって 推進してきたか?/How did we promote in-house development by starting from scratch?
genkiogasawara
1
150
エンジニアゼロの組織から内製開発の DX をどう実現したのか / How did we achieve DX in in-house development in an organization with zero engineers?
genkiogasawara
9
3.9k
入門 AWS Amplify Gen2 / Introduction to AWS Amplify Gen2
genkiogasawara
1
710
ソフトウェア開発の生産性と信頼性向上に取り組んだ結果、どうなった?/What has changed as a result of efforts to improve software development productivity and reliability?
genkiogasawara
0
75
「魔の川」「死の谷」をクラウド ネイティブなチーム作りで越境する / Crossing the "Devil River" and "Death Valley" by building cloud-native teams
genkiogasawara
2
450
Amazon CodeCatalyst で実現!開発環境とCI/CDパイプライン
genkiogasawara
0
7.4k
Other Decks in Technology
See All in Technology
Azure SQL Database Hyperscale HA レプリカの監視
sansantech
PRO
0
190
20240906_JAWS_Yamanashi_#1_leap_beyond_the_AWS_all_certifications
tsumita
1
100
トレタO/X アーキテクチャ移行記 Next.js App Router化への道のり / TORETA TECH UPDATE 1
okunokentaro
2
560
標準最高!標準はださくないぞ! at fukuoka.ts #1
yoiwamoto
0
150
Staff Engineer / 20240827 Yuichiro Masui
shift_evolve
0
150
エンジニア採用ノウハウ0から継続的な採用に至るまで / Try recruiting engineers
ohageeq
0
130
分野に潜むツールの紹介
pojiro
1
330
Estrategias de escalabilidade para projetos web
jessilyneh
1
150
歴史と背景から改めて振り返るVPC
shotashiratori
2
220
GraphQLとスキーマファーストで切り開く ライドシェアの未来
ku0522a
0
490
Hyperledger Fabricの成長、成熟を振り返る / Looking back history of Hyperledger Fabric
gakumura
0
180
FastConnect の冗長性
ocise
0
7.1k
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Side Projects
sachag
451
42k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Code Review Best Practice
trishagee
62
16k
Automating Front-end Workflow
addyosmani
1365
200k
The Straight Up "How To Draw Better" Workshop
denniskardys
230
130k
Speed Design
sergeychernyshev
18
400
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
33
1.7k
How To Stay Up To Date on Web Technology
chriscoyier
785
250k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
45
4.8k
Transcript
北海道ガス株式会社 小笠原 元気 クラウドネイティブな省エネサービスの 内製開発で、BizDevOpsを実現する 1 2024.6.15 CloudNative Days Summer
2024
⾃⼰紹介 Genki (⼩笠原 元気) 北海道ガス株式会社(2017〜) ・Job, Role フロントエンド・バックエンドエンジニア 開発チームのテックリード 趣味︓旅⾏・筋トレ
CloudNative Days 歴︓4年(2020初参加) 最近興味があること︓Next.js, Vercel @geivk 2
Agenda 会社 / プロジェクト(Mys3︓ミース)概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 Future
works・まとめ 3
今⽇のお話の内容 • クラウドネイティブで組織や事業の課題を解決した話 • 事業会社・事業部⾨だからこそ感じたクラウドやクラウドネイティブの良さ • 初⼼者スタートでも熱量とコミュニティで乗り切った話 4
Agenda 会社 / プロジェクト(Mys3︓ミース)概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ
5
北海道ガス株式会社 主要事業内容 本社所在地 従業員数 沿⾰ 1911年 設⽴ ガス事業 電気供給業 ガス機器販売
851名 札幌市東区北7条東2丁⽬1-1 売上⾼ 1,738億円(連結) 2024年3⽉末時点 お客さま 件数 ガス︓604,329件 電⼒︓254,956件 会社概要 6
業務⽤省エネサービス「Mys3(ミース)」 • 多額の初期投資が必要 • 既設設備の停⽌期間や⼤掛かりな⼯事が必要 • 中⼩規模向けの選択肢(少機能・低価格)が少ない。 Make your smart
solution service Mys(ミース): スウェーデン語で“楽しい・⼼地よい” の意 最新の技術を活⽤した多様なサービスで、お客さまの楽しい・ ⼼地よいを創造する意図を込めている。 業務⽤のお客さまで省エネ設備を導⼊する際の課題 こうしたお客さまの課題を、デジタル技術を⽤いて解決 北ガスグループ 独⾃開発 7
「Mys3(ミース)」i-Ch / REM 常時計測・監視、 ⾃動で省エネ制御 セントラル空調機器 当社クラウドシステム 冷温⽔(往) 冷温⽔(還) アタッチメント型
制御ユニットを設置 計測データの⾒える化 遠隔制御 吸収式冷温⽔機遠隔省エネサービス 当社クラウドシステム 計測データの⾒える化 CO2/温度/湿度 データ CO2・温湿度可視化サービス
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
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
Agenda 会社 / プロジェクト(Mys3︓ミース)概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ
11
CNCF Cloud Native Definition v1.1 • Cloud Native Computing Foundation(CNCF)
スケーラブルなアプリケーションの構築と実⾏するための能⼒ → 回復⼒・管理⼒・可観測性・疎結合アーキテクチャシステム ⾃動化 イミュータブル インフラストラクチャ 宣⾔的API コンテナ サービスメッシュ マイクロサービス 12
CNCF Cloud Native Definition v1.1 • Cloud Native Computing Foundation(CNCF)
スケーラブルなアプリケーションの構築と実⾏するための能⼒ → 回復⼒・管理⼒・可観測性・疎結合アーキテクチャシステム ⾃動化 イミュータブル インフラストラクチャ 宣⾔的API コンテナ サービスメッシュ マイクロサービス インパクトのある変更を最⼩限の労⼒で 頻繁に実⾏することが可能になる 13
Cloud Native glossary • クラウドネイティブアプリケーションは、クラウドアーキテクチャと容易に 統合でき、クラウドのリソースとスケーリング機能を活⽤できます。 • クラウドネイティブアプリケーションは弾⼒性があり、管理しやすく、それ に付随する⼀連のクラウドサービスによって⽀援されます。 さまざまなクラ
ウドサービスによって、⾼度なオブザーバビリティが有効になり、ユーザー は問題が深刻化する前に発⾒して対処することができます。 堅牢な⾃動化と 組み合わせることで、エンジニアは最⼩限の労⼒で、インパクトの⼤きい変 更を頻繁にかつ予想通りに⾏うことができます。 https://glossary.cncf.io/ja/ より引⽤ 14
クラウドネイティブで私たちは何が得られるのか︖ クラウドネイティブアプリケーションによる価値 新しいサービス・付加価値の 創出に注⼒できる お客さまに提供できる サービスの幅が広がる DX(Developer eXperience) 開発者体験の向上 15
Bizチーム・Devチーム・Opsチーム Biz, Dev, Ops チームがそれぞれのKPI を持っている状態 • 関⼼事は⾃チームの最⼤化 • 事業部⾨で初期から別々の組織で
進めていくのはかなりのハードル 予算・リソース・能⼒全てが不⾜ Biz Dev Ops 16
BizDevOps Biz, Dev, Ops チームが共通の KPI を持っ ている状態=密な連携 • 関⼼事は共通になっている
• お互いにそれぞれを理解している • ⾼速に概念検証を繰り返す • 継続的なサービスリリース / 改善 → 特に事業部⾨では BizDevOps が必要 Biz Dev Ops 17
Agenda 会社 / プロジェクト(Mys3︓ミース)概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ
Mys3 の構想の当初 19 低価格 最⼩機能(MVP) ⼤規模⼯事不要 ⾃動化 IoT クラウド 通信
プログラミング 市場 ニーズ 技術 シーズ ✔ ✔ ✔ ✔ ? ? ? ? ニーズはあったが、技術がなかった =Dev, Ops について知識がなかった
従来 エネルギー会社 SIer/ベンダー 2次請 3次請・・・ IT部⾨/システム系 グループ会社 当社の従来のシステム開発の課題 要件定義に⻑期間かかる 少しの画⾯修正で数⼗万
オーダーの発注 20 IoT クラウド 通信 プログラミング 技術 シーズ ? ? ? ? 多額の初期投資ができない状況+ 社内ナレッジの取得 ⇒ 内製開発へ
内製開発の始まり 2018年〜 クラウド/IT分野は技術・ビジネス の変化が激しい 2018/7⽉〜 社内有志メンバーで勉強会・ サークルを⽴ち上げ (プログラミングやIoT技術を中⼼に) 技術論者ではなく、技術的な思考と⾏動を 両⽴するスピーディな実践者の集まりが必要
クラウドは 良いですよ︕ それって、 おいしいですか︖ What is Cloud? はじめは「無知状態」 サーバーが何か知らなかった 21
業務⽤ 分野の EMS推進 経営のミッション DX ビ ジ ネ ス サ
イ ド 経営課題への 取り組み 内製開発のターニングポイント 新しい分野 への挑戦 熱源機器IoT化 内製開発による PoCスタート 若⼿の熱量 知的好奇⼼ ボ ト ム ア ッ プ 社内サークル ⽴ち上げ 22
しかし、内製開発のスタート時は・・・ エネルギーサービス業務 発電所業務 PdM 開発 ほかの業務と兼業からの スタート(現在も継続中) 23
◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 事業部⾨の内製開発が抱える BizDevOps の課題 24
事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆
開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 25
◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆ 開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え)
• オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 事業部⾨の内製開発が抱える BizDevOps の課題
Agenda 会社 / プロジェクト(Mys3︓ミース)概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 まとめ
27
クラウドネイティブのアプローチ ⾃動化 サービスメッシュ イミュータブル インフラストラクチャ コンテナ マイクロ サービス 宣⾔的 API
クラウドネイティブのアプローチやクラウドのメリットを 最⼤限利⽤し BizDevOps の課題を解決していった 28
事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆
開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 29
安価かつ⾃由度の⾼いサービスを提供するには︖ • 従来のシステム開発⼿法やデバイスで構築するの難しい ◆ システムの課題解決 • IoTのプラットフォームを作成 • 接続すれば遠隔計測・遠隔制御ができるようにしたい •
従量課⾦制のパブリッククラウドが最適 • 後からニーズに合わせて機能追加したい → マイクロサービス 30
安価かつ⾃由度の⾼いサービスを提供するには︖ • 従来のシステム開発⼿法やデバイスで構築するの難しい ◆ システムの課題解決 • IoTのプラットフォームを作成 • 接続すれば遠隔計測・遠隔制御ができるようにしたい •
従量課⾦制のパブリッククラウドが最適 • 後からニーズに合わせて機能追加したい → マイクロサービス ◆ デバイスの課題解決 • 当初、制御でよく使われる汎⽤のPLCを利⽤ • さらに安価にするためマイコン+IoTゲートウェイの構成に 31
「やってみた」の恩恵 • 知的好奇⼼をベースとした「やってみた」の実践 • 部署・部⾨を超えて⾃由に報告しあう社内コミュニティの役割 ▪技術習得 プログラミング⾔語 IoT技術 Raspberry Pi
ESP32 モノ 通信 クラウド ▪知⾒獲得 機械学習 画像処理 コンテナ 組込 フロント 昼休みハンズオン すべて独学 学習→熱量→実践→共有→・・・の好循環 32
環境と外部コミュニティ • 「やってみる」の熱量 • 「やってみなさい」の上司のサポート ⼼理的安全性や裁量があったことが重要 • 外部コミュニティへの参加 初⼼者ながら「やってみた」を JAWS
FESTA 2019 SAPPORO で発表 コミュニティの熱量を⽣で感じた クラウドの最新事例を常に収集できる 33
事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆
開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 34
マイクロサービスとは (イメージ) • 機能を異なるマイクロサービスに分離することにより、それらを独⽴して • デプロイ、アップデート、スケールすることが容易になります。 35 機能 A 機能
B 機能 C 機能 D 機能 A 機能 B 機能 C 機能 D モノリス マイクロサービス https://glossary.cncf.io/ja/ より引⽤
PoC のアーキテクチャ ◆ PoC • ほぼ SORACOM 完結したアーキテクチャ • AWS
上にデータレイク+パイプラインを構築 • デバイスの設定情報は直接 SSH で接続して書き換える (ここまでデータベース構築なし) CloudNative アプローチ マイクロサービス PLC modbus アナログ I/O 制御 信号 ゲートウェイ SORACOM AWS Cloud データ 遠隔操作 可視化 クラウド アダプタ IoT Core データレイク SSH 制御盤 36
サービスローンチ時のアーキテクチャ ◆ サービスローンチ仕様 • フロントエンドからデバイスの設定情報を書き換えたい • 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
宣⾔的 API(イメージ) • ⽬的の状態を定義(設定ファイルのイメージ) • コントローラが⽬的状態と差分をチェックし⽬的の状態へ⾃⼰修復する 38 https://glossary.cncf.io/ja/ より引⽤ 設定情報
コンテナの数︓10 コントローラ
サービスローンチ時のアーキテクチャ ◆ サービスローンチ仕様 • 可視化画⾯を SaaS からセルフホストに変更(OSS︓Grafana) • データベースとして時系列DB・Key-Value DBを採⽤
• コンテナオーケストレーションサービスの宣⾔的 API で運⽤の省⼒化 CloudNative アプローチ コンテナ・宣⾔的API AWS IoT Core Amazon Timestream (時系列DB) Amazon DynamoDB (Key-Value DB) Amazon ECS コンテナ オーケストレーション 39
アーキテクチャの段階的な変更 • クラウドならではの「リソースの使い捨て」 ワンクリックでリソースを起動、失敗した時にすぐリソースを廃棄できる • アーキテクチャをその段階の最適なものに変えられる PoC→サービスローンチ時 ビッグバンの移⾏ではなく拡張性が必要な箇所から、機能を徐々に移⾏できる CloudNative アプローチ
マイクロサービス 40
事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆
開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 41
コンテナとは(イメージ) • コンピューターのオペレーティングシステムがリソースと機能⾯で制限を管 理する、実⾏中のプロセス • コンテナイメージとしてパッケージ化されている 42 https://glossary.cncf.io/ja/ より引⽤ ランタイム
ライブラリ 設定 コンテナイメージ ビルド コンテナ
開発環境の設定のハードル 事業会社で内製開発をする悩み︓新⼊社員教育でプログラミングがないこと • 初⼼者には環境設定のハードルが⾼い • オンボーディングの場合も周辺ツールが多すぎてハードルが⾼い Python インストール Python を
homebrew で… Docker・git ・CDK も… Node.js もお願いします main ブランチから git clone してください 開発にJoin したメンバー (初⼼者) ・・・ PATH 設定 必要です CloudNative アプローチ コンテナ 43
開発環境の設定のハードルの解決 ◆ 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
事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆
開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 45
イミュータブルインフラストラクチャ(イメージ) • ⼀度デプロイされると変更することができないインフラストラクチャ =インフラは使い捨て、変更があるたびに再構築する 46 https://glossary.cncf.io/ja/ より引⽤ v1 v2 v3
構築 再構築 再構築 機能追加 パッチ Infrastructure as Code
Infrastructure as Code: IaC • 当初は、簡単な ETL の関数のみのためコンソールから作成 • API
ゲートウェイ+サーバレスファンクションで構築 • フロントエンドからの要件増 → サーバレスファンクションの数が増⼤ CloudNative アプローチ イミュータブルインフラストラクチャ ETL 遠隔指令 通信確認 設定情報取得 デバイス取得 エラーロガー 設定履歴 データクエリ デバイス認証 ETL etc. 47
Infrastructure as Code: IaC • いつ・誰が・どのファンクションを・どのように変更したかわからない • 認知負荷・管理⼯数⼤ → Infrastructure
as Code で管理 • Terraform or AWS CDK → IoT リソースに対応している AWS CDK を採⽤ ◆ ⾔語の選定 • 最初は Python で記述していたが型がない • 必須プロパティなども毎回 Document で調べなくてはいけない → 途中から、Python から TypeScript に全⾯移⾏ CloudNative アプローチ イミュータブルインフラストラクチャ 48
事業部⾨の内製開発が抱える BizDevOps の課題 ◆ ビジネスの課題︓安価で⾃由度の⾼いサービス • 早期にペイするようなサービス設計 • 切り売りができる組み合わせ⾃由度の⾼いサービス提供 ◆
開発の課題︓周辺ツールの理解のハードルと開発の柔軟性 • アーキテクチャの柔軟な変更(SaaSからの乗り換え) • オンボーディングの環境構築のハードルの⾼さ • クラウドインフラの複雑化 ◆ 運⽤の課題︓とにかく省⼒化・⾃動化 • ⼿作業によるデプロイでオペレーションミス・属⼈化・複雑なプロセス • インフラ管理の省⼒化 49
IaC の⾃動デプロイ • 当初、3つの環境にそれぞれ⼿動デプロイしていた • 開発者も開発環境に毎回デプロイが必要になっていた • オペレーションミスが発⽣し、特定の⼈がいないとデプロイできない • ビッグバンデプロイになりがちだった
dev (開発環境) stage (テスト環境) 開発者 prod (本番環境) デプロイ 職⼈による デプロイ CloudNative アプローチ ⾃動化 50
51 dev (開発環境) stage (テスト環境) 開発者 Repo git push Workflow
Repo/ Issue プルリク 作成 Workflow 承認 デプロイ デプロイ prod (本番環境) ⼿動テスト (デバイス) Workflow Repo デプロイ プルリク 作成 承認 Amazon CodeCatalyst テストの⾃動化・デプロイの⾃動パイプラインを構築 CI/CD パイプラインの構築 CloudNative アプローチ ⾃動化・コンテナ
テストの重要性 • テスト・・・とは・・・︖ 何から⼿をつけたらいいかわからない状態 継続的インテグレーション / デプロイの⾼頻度デプロイ → 既存の機能が担保されているという意味でテストが重要 ü
AWS CDK を TypeScript に移⾏するタイミングでテストを導⼊ ü バックエンドのロジックにもテストを導⼊ • ただし開発⼈員が限られているため、コア機能にテストを集約 CloudNative アプローチ ⾃動化 52
Agenda 会社 / プロジェクト(Mys3︓ミース)概要 クラウドネイティブと BizDevOps とは︖ 内製開発の取り組みとその課題 課題解決のためのクラウドネイティブ技術 Future
works・まとめ
サービスローンチ後の機能追加 • サービスローンチ後も、お客さまからのフィードバックで機能を実装 • 曜⽇別・時間別のスケジュール運転機能 • 気象情報による天気に連動した運転機能 • 他の機器への拡張性・・・etc. デバイスへの実装は、影響が⼤きい
クラウドにて素早く・柔軟に実装 ⾼速に実装し検証しながら フィードバックをもらう お客さま 開発チーム (お客さまに近い⽴場) 54
FUTURE WORKS ◆ クラウドサービス • CSPM: Sysdig CSPM の利⽤検討(オペレーションコスト低減) •
RDB: TiDB Serverless に移⾏できないか検討(コスト低減) 開発当初より多様かつ、さらに安価なサービスが出ている 55
FUTURE WORKS ◆ クラウドサービス • CSPM: Sysdig CSPM の利⽤検討(オペレーションコスト低減) •
RDB: TiDB Serverless に移⾏できないか検討(コスト低減) 開発当初より多様かつ、さらに安価なサービスが出ている ◆ ⽣成 AI • ⼈数が少ないからこそ、⽣成 AI をフル活⽤したい • ローカル LLM や コード⽣成、Github Copilot Workspace など 進化が著しいため、特定のサービスにとらわれずトライしたい 56
まとめ • 内製開発こそ、クラウドネイティブの考えを取り⼊れるべき 事業により注⼒できるようになるメリットが⾮常に⼤きい • 社外コミュニティで熱量を感じ、最新のクラウドネイティブ事例を取り⼊れる 社内のコミュニティでまずは「やってみた」を実践 • クラウドネイティブをすぐに取り⼊れられなくても、知っていることが重要 →
事業化・サービス化のどこかで必要なタイミングが出てくる • クラウドネイティブを取り⼊れたことで BizDevOps を実現できた お客さまのフィードバックから機能実装することができている 57
Thank you!