アジャイル開発と時代の流れに伴うサーバレスアーキテクチャの変化

アジャイル開発と時代の流れに伴う
サーバレスアーキテクチャの変化
KDDIアジャイル開発センター株式会社

View Slide

1
KDDI Agile Development Center Corporation
今だにサーバレスなサービスが使える要件なのに
使おうとしない全てのエンタープライズな会社に捧ぐ

View Slide

2
⾃⼰紹介
経歴
・前職:
Amazon Web Services Japan(AWS) : 技術⽀援
・現職:
・⼤規模アジャイルチームの技術コンサル / 開発⽀援
・社内新規事業⽴ち上げ
・コミュニティ活動の推進や OSS 活動の推進
・群⾺拠点サテライトオフィス⻑
・海外スタートアップ:
MomentoにてCommunity Advocateとして活動
資格・ポートフォリオ・参加コミュニティ
YOSHITAKA KOITABASHI
⼩板橋由誉
[資格・ポートフォリオ]
aws solution architect professional
電⼦情報通信学会情報ネットワーク研究会第5回情報ネットワーク若⼿研究奨励賞受賞
[コミュニティ]
Tech-on / Jaws-ug コンテナ⽀部
X(Twitter) / Qiita/ Zenn: Yoshii0110
GitHub: Yoshiitaka

View Slide

3
本⽇お話しする中における
サーバレスの定義は、
アプリケーションエンジニアにとって
扱いが楽であり、市場に対してより素早く
ソフトウェアを送り出すことができる。
かつサービスに柔軟性、耐久性を持つものとします。

View Slide

4
アジェンダ
• KDDIアジャイル開発センター(KAG)とは︖/ 過去と現在
• 扱ってきた事例とアーキテクチャ
• アジャイル開発。我々が⽬指したいこと
• これからのサーバレスアーキテクチャと
ソフトウェア開発におけるライフサイクルの話
• 最後に

View Slide

5
re-INNOVATE YOUR BUSINESS
”Be Agile, Update Culture”
What’s K.A.G. ?

View Slide

6
What’s KAG?
約10年間“アジャイル開発”に
徹底的にこだわり続けてきた
DX専業のエンジニア集団
Mission
re-INNOVATE YOUR BUSINESS
”Be Agile, Update Culture”
アジャイルに⼒を与え、
共に成⻑し続ける社会を創る
DXが求められる時代において
私たちは、変化を恐れず、新たな価値観、新技術を取り⼊れ
絶えずアップデートし続けることで新しい価値を創り出してきました
「変化と共に⽣きる」
我々と⼀緒にアジャイルな⽂化・組織を築き
⾃らの⼿で新たなビジネスをカタチにしませんか
2022年7⽉事業開始

View Slide

7
KDDIにおけるアジャイル開発の歩み
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
開発案件拡⼤
オフショア
ニアショア
法⼈向けクラウドサービス
KDDI BusinessIDにて
初のアジャイル開発導⼊
アジャイル開発センター発⾜
（様々な部⾨でAgile開始）
共創ビジネス創出へ
DX
領域拡⼤（Personal）
auでんき
auHOME（IoT）
顧客視点強化
UI/UX取り組み強化・加速
KDDI DIGITAL GATE
Scrum inc. Japan設⽴

View Slide

8
時は2014年に遡る
• 2014年ごろに開発されていたある
「契約⼀元管理システム」を例に挙げる
• この当時、基盤は⾃社開発していた
国産クラウド(cloudstack採⽤)で
cloudstack等で管理するVM上に
各種サーバ群たて⾯倒⾒る
• アジャイル開発のサイクルを回しつつ
• 運⽤体制はどうしていたか
=> 24/365電話対応をしていた

View Slide

9
⾃由な世界を夢⾒ていた
ただ・・⾃由が欲しかったんだ

View Slide

10
KDDIのCCoEチームの躍動
• 2013年あたりに社内でAWSを
本格的に使えるよう整備する為、
CCoEチームが動き出す
• 本格始動までに3年強かかり
2016年に運⽤開始
出典元: https://speakerdeck.com/mamohacy/entapuraizuqi-ye-niokeruawszheng-shi-
cai-yong-hefalsetiao-zhan-regasiwowei-xiao-minikaete
某mamohacyさんがハンマーで
頭をかち割られたのが2013年

View Slide

11
解放⾃由

View Slide

12
2016~18年に時代は流れ
フロントエンド APIサーバ
よくある構成

View Slide

13
Home IoTの例: ①
• 2017年くらいの事例だが、
Home IoTの基盤をAWSで構築
• 使⽤しているものとして、
Lambda、DynamoDBなどを
上⼿く利⽤しているパターン

View Slide

14
Home IoT周りの例: ②
• こちらの事例も先ほどと同様にVPCを使わなければいけない箇所と
そうでない箇所を使い分け、API Gateway + Lambdaや
DynamoDB + Lambdaの構成を取り⼊れていた

View Slide

15
あるサービスの監視基盤例
• 管理基盤についても
AWSを利⽤する形へと変化。
• アプリケーションログやサービスログに
ついてはCloudWatchからKinesis Data
Stream経由でLambda、そして
Datadogに送りSlackでアラートを
検知するような作りをとるケースもあった

View Slide

16
その後、2020年頃〜
教育系サービス基盤
• 2020年ごろになると社内でのAWSの知
⾒を持つエンジニアも増え、より複雑な
構成でサーバレスサービスを活⽤する
ように変化
• この事例だと対向先のサービス要件に
引きづられでPrivateLinkを
張らざるおえない形となっているが、
インフラはなるべくサーバレスサービス
を活⽤したいため、VPC + Lambdaを
使ったり、イベント駆動な設計を
活⽤したりする。

View Slide

17
2020年頃にあったサービスの
継続的インテグレーション / 継続的デリバリーの仕組み
・テスト
・ビルド
・デプロイ
CircleCI
開発者
静的コードレビュー
push
merge
・リグレッションテスト
（15分に1回）
・モニタリング
yamory
OSS脆弱性診断
・テスト
・ビルド
・デプロイ
CircleCI
Bitrise
・テスト
・ビルド
・デプロイ
DeployGate
push
merge
AWS Cloud

View Slide

18
2020年ごろの技術スタック⼀覧
Collaborate Build Test Deploy Run
• Jenkins
• CircleCI
• Drone
• Sider
• Bamboo
• AWS
CodePipeline
• Bitrise
CI/CD
• JIRA
• Trello
Lifecycle Mgmt SCM
• Github
• Bitbuket
Testing
• Gatling
• artillery
• Selenium
• Appium
• terratest
• ServerSpec
• Testcafe
Configuration
• Terraform
• CloudFormation
• Amplify
• Fargate
• Ansible
• Chef
• Vagrant
• Rundeck
Cloud
• AWS
• KCPS
• GCP
Communication
• Slack
• Chatwork
• VS Code share
Security
• Black Duck
• yamory
• Snyk
• SonerCube
Chaos
• Gremlin
Container Registry
• Amazon ECR
• Google Container
Registry
• Docker Registry
Monitoring
• Datadog
• Instana
• New Relic
• Cloudwatch
• Google
Stackdriver
• mackerel
• Zabbix
Knowledge sharing
• Confluence
• Github pages

View Slide

19
そして2021年あたり〜現在
MaaSの事例のアーキテクチャ例
• とあるMaaSの例ですが、特徴的
なのはAmazon Neptuneを
データストアとして利⽤している
ものの、それ以外の箇所は
ほぼ全てサーバレスサービスで
構成されている
AWS DevDay2022 「Amazon Neptuneとサーバレスから始まった⾼速バス
予約システム開発」
出典: https://speakerdeck.com/curanosuke/awsdevday-japan-2022-
amazon-neptune-and-serverless

View Slide

20
MaaSの事例(AWS + 分析基盤としてGoogle Cloud)
こちら⼀例ではあるものの、
データ分析基盤について、
AWS内で集約したデータを
Glueを使いStepfunctions経由
でパラレルに呼び出し、加⼯した
データをGoogle Cloud側で分析
するようなアーキテクチャを採⽤

View Slide

21
変化したデプロイ⼿法の例
• デプロイのされ⽅も変化。
• 基本サーバレスサービスを
利⽤することが多くなっていく中で、
GitHub Actions経由で
Serverless Frameworkにて資源
を管理するチームもいる

View Slide

22
KDDI Engineer Portal
リンク: https://developers.kddi.com/
社外⽤ブログ
社内⽤ブログ
• 会社ブログを作成したタイミングで、
本来であればvercelを使いたかったの
だが、諸事情によりAWSを採⽤
• Fargateをより楽にしたコンテナ
サービスApp Runnerを使⽤した
アーキテクチャとなる

View Slide

23
タビトシゴト
リンク: https://tabitoshigoto.com/
構成: SSG + Headless CMS (OSS)
• 今年の2⽉にリリースした新規
サービスにおいては、
フロントエンドにAmplify、
バックエンドにはOSSで提供さ
れているHeadless CMSである
Strapiを採⽤
• データストアとして
Aurora Serverlessを採⽤
• 社⻑へのピッチから
3ヶ⽉でリリース

View Slide

24
⾃由の翼は⼿に⼊れた。
我々が次に向かうのは︖

View Slide

25
“予測不能な時代”と”想像を超えるテクノロジーの進化”

View Slide

26
変化のスピードはより加速している
変化に迅速で、かつ顧客が欲しい価値を
届ける必要がある
世の中は予測が難しいVUCAの時代
デジタルによる変化も急激に加速
企業もその変化に対応し、
どのようにビジネス/プロダクトを
産み出して適応させるかが重要
V olatility 変動性
U ncertainty 不確実性
C omplexity 複雑性
A mbiguity 曖昧性

View Slide

27
どういったサービスが適切か
顧客中⼼
サービス
顧客がほしい
ニーズ
体験
顧客が利⽤するものが
揃っており、
余計なモノがない
サービス
顧客がほしい
ニーズ
体験
⼀番利⽤するものが⾜りてなく、
余計なモノが多い

View Slide

28
アジャイルのマインドセットを持つこと
フィードバックが
得られる成果物
出典︓Scrum inc.
アジャイルとは顧客の価値を中⼼に置くことから始まる
計画に従うより変化への対応
包括的なドキュメントより動くプロダクト
プロセスやツールより個⼈との対話契約交渉より顧客との協調

View Slide

29
顧客との協調
顧客は最初から欲しいものは判らない
顧客からのフィードバックを早く、頻繁に得ることで、
顧客の求める価値を顧客と共に⾒出す
⼿戻りによるムダな作業を避ける
出典︓Scrum inc.

View Slide

30
実際に動くプロダクトとイテレーション
出典︓Space X.

View Slide

31
どのように進めていくか
デザイン
シンキング
アジャイル
スクラム
リーン
スタートアップ
解決すべき課題を
ユーザ視点で探索する
構築・計測・学習の
サイクルを小さく早く回す
改善を繰り返し
より良い価値を届ける

View Slide

32
アジャイル開発の⼿法
アジャイル開発を実現する⼿法はさまざまですが代表的な⼿法として、
以下のようなものが挙げられます。
XP カンバン
スクラム

View Slide

33
スクラム開発の例
開発価値の選択、
開発、
振り返りのサイクル
（スプリント）
を⼀定の周期で繰り返す
開発
スプリントレビュー＆振り返り
1 2
ユーザー
ストーリーを作成
プロダクト
バックログを作成
ユーザーストーリーベース
で必要なプロダクトの価値
をリストアップする。
開発チームにより動くもの
を作る。
成果物として動作するソフトウェアのデモおよび
フィードバック、改善事項（KPTなど）を話し合う。
価値1
価値2
価値3
価値4
スプリント計画会議
（1〜2週間に1回）
スプリント期間内に開発する価値を選択する。
価値2
価値3
価値4
3pt
8pt
1pt
機能5
機能6
優先
順位
付け
⼯数
⾒積
スコープ調整
3
4
5
価値1 8pt
リリース
可能な
プロダクト
複数回
スプリントを
繰り返す
Keep
Problem
Try 価値1
価値2
価値3
価値4
クロスファンクショナル
チームを構成
スクラムチーム
０

View Slide

34
ここで⼀度原点に⽴ち返り
ソフトウェア⼯学の観点から開発プロセスに
ついてを⾒直してみる。

View Slide

35
ソフトウェア⼯学
• ソフトウェア⼯学とは、ソフトウェアの現実的な
問題に対する”効率的”、”経済的”な解を
⾒つけるための経験的かつ科学的な
アプローチの応⽤。
• “効率的”で”経済的”であることを⽬指すなら、
学びの能⼒は持続できるようにしないといけない
=> 新しいことを学び続ける環境を
保てるようにするためには、
今作っているシステムの複雑さ(インフラな
のか、アーキテクチャなのか、コードなのか
組織なのか等々)を管理しなければならない
おすすめな書籍
(出典元)

View Slide

36
⼯学 VS ソフトウェア⼯学
• 例えば、船を作るエンジニアと
ソフトウェアを作るエンジニアを⽐較する
◦ 船を作る場合、実際の実物ができるまでは例えコンピュータシミュレータで
シミュレーションしたとしても、シミュレータで作られたものは
現実に近いものとしかならない。
なので、実際に何度も作るかと⾔ったらそんなお⾦はかけられない。
つまりいてレーションできない。
◦ 逆にソフトウェアを作るエンジニアは、ある作りたいソフトウェアの形で
作るモデルやシミュレータは、”作りたいもの”そのままとなる。

View Slide

37
素早くソフトウェアが
動かせる環境や
サービスがあるのに
使わない⼿はないよね︖

View Slide

38
サーバレスとアジャイル開発とのつらみ
• “真にお客様の欲しい機能を⾒つける”にはイテレーションを繰り返すしかない。
• だが、スプリントの中で例えばソフトウェアが載っているサービスに
メンテナンスウィンドウの通知が来るとか、パッチがきたから
影響範囲確認のためにリリースを1週ずらしましょうとか、
ユーザのアクセスが⾒込めない時期が来るから
⼿動でスケール値の設定するタスクを積んだら
ソフトウェア書く時間無くなりましたとか

View Slide

39
これでいいんでしたっけ。︖

View Slide

40
開発者が本当にやりたいことは
• イテレーションを繰り返し短期間でフィードバックを求めるサイクルを
回すには、なるべくソフトウェアを書く時間を確保したいはず。
=>そうなると必然と取りうる選択肢は、サーバレスになるはず

View Slide

41
サーバレスアーキテクチャとソフトウェア開発
• ソフトウェア開発に広く適⽤できる汎⽤的なプラクティス、
コンポーネント、それらを多くのチームが正しく理解し使いこなせれば、
⽣産性が上がりチームメンバーのストレスが消え、設計の品質は向上し、
作ったシステムの耐久性は上がる。
=> これはサーバレスアーキテクチャも同じ。
• ここには使い古されたアーキテクチャがダメということはなく、
むしろそれにより圧倒的に知⾒が増えバグが減ることで
そのソフトウェアがメリットを享受できる

View Slide

42
これからのサーバレスアーキテクチャ
• 歴史の中で触れられたように現在、1つのクラウドサービスの中で
全てを完結させる必要はない。
• SaaS、PaaS、FaaSなのか分からないがその時々に使いたいもの、
様々なサービスと⽐較し最適だと判断したもので組み上げていく。
そんな流れになっている。
• 例えば、キャッシュであればMomento、SQLを扱うならTiDB。
SSGされたフロントエンドをホスティングし、
よりサービス体験が早くさせたいならCloudflareなど。

View Slide

43

View Slide

44
これからのサーバレスアーキテクチャと
ソフトウェア開発におけるライフサイクルの話
• ここにソフトウェア開発におけるライフサイクルの話を混ぜて考えてみる。
• これらのサーバレスサービスを組み合わせると何が起きるのか。
=> そのどれもがインフラのコード化なんてものはない。
• 確かに専⽤のconfigファイルを設定しないといけない場合もあるが、
その中にインスタンスの容量やスケーリングの設定などというものはない。
• もっと⾔えば、GitHubなどのソースコードのバージョン管理
プラットフォームにただアプリケーションコードをpushするだけで
サービス全体がデプロイされたことになる。

View Slide

45
⾃由な技術から
最適な選択肢を選べる

View Slide

46
Whatʼs Next?
我々の道のりはまだまだ⻑いです。
⽇本に真のアジャイル開発と技術を組み合わせ、
ソフトウェアを開発する。
しかし、僕らはたくさんの新技術が使える環境で、
どんどん学び検証し、知⾒を横展開していくだけで良いのか︖
いいえ、そうではありません。
市場に対して事業をグロースする中で新技術が使え、
知⾒を横展開できる形に組織から
変えていかなければならないのです。
そのためには⼀緒に組織作りから考えられる
エンジニアを募集しています。

View Slide

47
採⽤募集中︕
エンジニア・デザイナー

View Slide

Be a Change Leader.
アジャイルに⼒を与え
共に成⻑し続ける社会を創る

View Slide

アジャイル開発と時代の流れに伴うサーバレスアーキテクチャの変化

アジャイル開発と時代の流れに伴うサーバレスアーキテクチャの変化

yoshitaka KOITABASHI

More Decks by yoshitaka KOITABASHI

Other Decks in Technology

Featured

Transcript