Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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

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

yoshitaka KOITABASHI

September 24, 2023
Tweet

More Decks by yoshitaka KOITABASHI

Other Decks in Technology

Transcript

  1. 2 KDDI Agile Development Center Corporation ⾃⼰紹介 経歴 ・前職: 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
  2. 4 KDDI Agile Development Center Corporation アジェンダ • KDDIアジャイル開発センター(KAG)とは︖/ 過去と現在

    • 扱ってきた事例とアーキテクチャ • アジャイル開発。我々が⽬指したいこと • これからのサーバレスアーキテクチャと ソフトウェア開発におけるライフサイクルの話 • 最後に
  3. 6 KDDI Agile Development Center Corporation What’s KAG? 約10年間“アジャイル開発”に 徹底的にこだわり続けてきた

    DX専業のエンジニア集団 Mission re-INNOVATE YOUR BUSINESS ”Be Agile, Update Culture” アジャイルに⼒を与え、 共に成⻑し続ける社会を創る DXが求められる時代において 私たちは、変化を恐れず、新たな価値観、新技術を取り⼊れ 絶えずアップデートし続けることで新しい価値を創り出してきました 「変化と共に⽣きる」 我々と⼀緒にアジャイルな⽂化・組織を築き ⾃らの⼿で新たなビジネスをカタチにしませんか 2022年7⽉事業開始
  4. 7 KDDI Agile Development Center Corporation 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設⽴
  5. 8 KDDI Agile Development Center Corporation 時は2014年に遡る • 2014年ごろに開発されていたある 「契約⼀元管理システム」を例に挙げる

    • この当時、基盤は⾃社開発していた 国産クラウド(cloudstack採⽤)で cloudstack等で管理するVM上に 各種サーバ群たて⾯倒⾒る • アジャイル開発のサイクルを回しつつ • 運⽤体制はどうしていたか => 24/365電話対応をしていた
  6. 10 KDDI Agile Development Center Corporation KDDIのCCoEチームの躍動 • 2013年あたりに社内でAWSを 本格的に使えるよう整備する為、

    CCoEチームが動き出す • 本格始動までに3年強かかり 2016年に運⽤開始 出典元: https://speakerdeck.com/mamohacy/entapuraizuqi-ye-niokeruawszheng-shi- cai-yong-hefalsetiao-zhan-regasiwowei-xiao-minikaete 某mamohacyさんがハンマーで 頭をかち割られたのが2013年
  7. 13 KDDI Agile Development Center Corporation 2016~18年に時代は流れ Home IoTの例: ①

    • 2017年くらいの事例だが、 Home IoTの基盤をAWSで構築 • 使⽤しているものとして、 Lambda、DynamoDBなどを 上⼿く利⽤しているパターン
  8. 14 KDDI Agile Development Center Corporation 2016~18年に時代は流れ Home IoT周りの例: ②

    • こちらの事例も先ほどと同様にVPCを使わなければいけない箇所と そうでない箇所を使い分け、API Gateway + Lambdaや DynamoDB + Lambdaの構成を取り⼊れていた
  9. 15 KDDI Agile Development Center Corporation 2016~18年に時代は流れ あるサービスの監視基盤例 • 管理基盤についても

    AWSを利⽤する形へと変化。 • アプリケーションログやサービスログに ついてはCloudWatchからKinesis Data Stream経由でLambda、そして Datadogに送りSlackでアラートを 検知するような作りをとるケースもあった
  10. 16 KDDI Agile Development Center Corporation その後、2020年頃〜 教育系サービス基盤 • 2020年ごろになると社内でのAWSの知

    ⾒を持つエンジニアも増え、より複雑な 構成でサーバレスサービスを活⽤する ように変化 • この事例だと対向先のサービス要件に 引きづられでPrivateLinkを 張らざるおえない形となっているが、 インフラはなるべくサーバレスサービス を活⽤したいため、VPC + Lambdaを 使ったり、イベント駆動な設計を 活⽤したりする。
  11. 17 KDDI Agile Development Center Corporation 2020年頃にあったサービスの 継続的インテグレーション / 継続的デリバリーの仕組み

    ・テスト ・ビルド ・デプロイ CircleCI 開発者 静的コードレビュー push merge ・リグレッションテスト (15分に1回) ・モニタリング yamory OSS脆弱性診断 ・テスト ・ビルド ・デプロイ CircleCI Bitrise ・テスト ・ビルド ・デプロイ DeployGate push merge AWS Cloud
  12. 18 KDDI Agile Development Center Corporation 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
  13. 19 KDDI Agile Development Center Corporation そして2021年あたり〜現在 MaaSの事例のアーキテクチャ例 • とあるMaaSの例ですが、特徴的

    なのはAmazon Neptuneを データストアとして利⽤している ものの、それ以外の箇所は ほぼ全てサーバレスサービスで 構成されている AWS DevDay2022 「Amazon Neptuneとサーバレスから始まった⾼速バス 予約システム開発」 出典: https://speakerdeck.com/curanosuke/awsdevday-japan-2022- amazon-neptune-and-serverless
  14. 20 KDDI Agile Development Center Corporation そして2021年あたり〜現在 MaaSの事例(AWS + 分析基盤としてGoogle

    Cloud) こちら⼀例ではあるものの、 データ分析基盤について、 AWS内で集約したデータを Glueを使いStepfunctions経由 でパラレルに呼び出し、加⼯した データをGoogle Cloud側で分析 するようなアーキテクチャを採⽤
  15. 21 KDDI Agile Development Center Corporation そして2021年あたり〜現在 変化したデプロイ⼿法の例 • デプロイのされ⽅も変化。

    • 基本サーバレスサービスを 利⽤することが多くなっていく中で、 GitHub Actions経由で Serverless Frameworkにて資源 を管理するチームもいる
  16. 22 KDDI Agile Development Center Corporation そして2021年あたり〜現在 KDDI Engineer Portal

    リンク: https://developers.kddi.com/ 社外⽤ブログ 社内⽤ブログ • 会社ブログを作成したタイミングで、 本来であればvercelを使いたかったの だが、諸事情によりAWSを採⽤ • Fargateをより楽にしたコンテナ サービスApp Runnerを使⽤した アーキテクチャとなる
  17. 23 KDDI Agile Development Center Corporation そして2021年あたり〜現在 タビトシゴト リンク: https://tabitoshigoto.com/

    構成: SSG + Headless CMS (OSS) • 今年の2⽉にリリースした新規 サービスにおいては、 フロントエンドにAmplify、 バックエンドにはOSSで提供さ れているHeadless CMSである Strapiを採⽤ • データストアとして Aurora Serverlessを採⽤ • 社⻑へのピッチから 3ヶ⽉でリリース
  18. 26 KDDI Agile Development Center Corporation 変化のスピードはより加速している 変化に迅速で、かつ顧客が欲しい価値を 届ける必要がある 世の中は予測が難しいVUCAの時代

    デジタルによる変化も急激に加速 企業もその変化に対応し、 どのようにビジネス/プロダクトを 産み出して適応させるかが重要 V olatility 変動性 U ncertainty 不確実性 C omplexity 複雑性 A mbiguity 曖昧性
  19. 27 KDDI Agile Development Center Corporation どういったサービスが適切か 顧客中⼼ サービス 顧客がほしい

    ニーズ 体験 顧客が利⽤するものが 揃っており、 余計なモノがない サービス 顧客がほしい ニーズ 体験 ⼀番利⽤するものが⾜りてなく、 余計なモノが多い
  20. 28 KDDI Agile Development Center Corporation アジャイルのマインドセットを持つこと フィードバックが 得られる成果物 出典︓Scrum

    inc. アジャイルとは顧客の価値を中⼼に置くことから始まる 計画に従うより変化への対応 包括的なドキュメントより動くプロダクト プロセスやツールより個⼈との対話 契約交渉より顧客との協調
  21. 31 KDDI Agile Development Center Corporation どのように進めていくか デザイン シンキング アジャイル

    スクラム リーン スタートアップ 解決すべき課題を ユーザ視点で探索する 構築・計測・学習の サイクルを小さく早く回す 改善を繰り返し より良い価値を届ける
  22. 33 KDDI Agile Development Center Corporation スクラム開発の例 開発価値の選択、 開発、 振り返りのサイクル

    (スプリント) を⼀定の周期で繰り返す 開発 スプリントレビュー&振り返り 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 クロスファンクショナル チームを構成 スクラムチーム 0
  23. 35 KDDI Agile Development Center Corporation ソフトウェア⼯学 • ソフトウェア⼯学とは、ソフトウェアの現実的な 問題に対する”効率的”、”経済的”な解を

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

    例えば、船を作るエンジニアと ソフトウェアを作るエンジニアを⽐較する ◦ 船を作る場合、実際の実物ができるまでは例えコンピュータシミュレータで シミュレーションしたとしても、シミュレータで作られたものは 現実に近いものとしかならない。 なので、実際に何度も作るかと⾔ったらそんなお⾦はかけられない。 つまりいてレーションできない。 ◦ 逆にソフトウェアを作るエンジニアは、ある作りたいソフトウェアの形で 作るモデルやシミュレータは、”作りたいもの”そのままとなる。
  25. 38 KDDI Agile Development Center Corporation サーバレスとアジャイル開発とのつらみ • “真にお客様の欲しい機能を⾒つける”にはイテレーションを繰り返すしかない。 •

    だが、スプリントの中で例えばソフトウェアが載っているサービスに メンテナンスウィンドウの通知が来るとか、パッチがきたから 影響範囲確認のためにリリースを1週ずらしましょうとか、 ユーザのアクセスが⾒込めない時期が来るから ⼿動でスケール値の設定するタスクを積んだら ソフトウェア書く時間無くなりましたとか
  26. 41 KDDI Agile Development Center Corporation サーバレスアーキテクチャとソフトウェア開発 • ソフトウェア開発に広く適⽤できる汎⽤的なプラクティス、 コンポーネント、それらを多くのチームが正しく理解し使いこなせれば、

    ⽣産性が上がりチームメンバーのストレスが消え、設計の品質は向上し、 作ったシステムの耐久性は上がる。 => これはサーバレスアーキテクチャも同じ。 • ここには使い古されたアーキテクチャがダメということはなく、 むしろそれにより圧倒的に知⾒が増えバグが減ることで そのソフトウェアがメリットを享受できる
  27. 42 KDDI Agile Development Center Corporation これからのサーバレスアーキテクチャ • 歴史の中で触れられたように現在、1つのクラウドサービスの中で 全てを完結させる必要はない。

    • SaaS、PaaS、FaaSなのか分からないがその時々に使いたいもの、 様々なサービスと⽐較し最適だと判断したもので組み上げていく。 そんな流れになっている。 • 例えば、キャッシュであればMomento、SQLを扱うならTiDB。 SSGされたフロントエンドをホスティングし、 よりサービス体験が早くさせたいならCloudflareなど。
  28. 44 KDDI Agile Development Center Corporation これからのサーバレスアーキテクチャと ソフトウェア開発におけるライフサイクルの話 • ここにソフトウェア開発におけるライフサイクルの話を混ぜて考えてみる。

    • これらのサーバレスサービスを組み合わせると何が起きるのか。 => そのどれもがインフラのコード化なんてものはない。 • 確かに専⽤のconfigファイルを設定しないといけない場合もあるが、 その中にインスタンスの容量やスケーリングの設定などというものはない。 • もっと⾔えば、GitHubなどのソースコードのバージョン管理 プラットフォームにただアプリケーションコードをpushするだけで サービス全体がデプロイされたことになる。
  29. 46 KDDI Agile Development Center Corporation Whatʼs Next? 我々の道のりはまだまだ⻑いです。 ⽇本に真のアジャイル開発と技術を組み合わせ、

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