開発を牽引するエンジニアのためのテクニカルカンファレンス「AWS Dev Day 2023 Tokyo」｜2023年 6 月 22日（木）～ 23 日（金）開催

AWS Dev Day 2023 Tokyoに参加してきました！
AI、コンテナ、サーバーレス、マイクロサービス関連のセッションを主に受講しています。
参加前にイベントサイトに記載のセッション概要から質問・疑問を考えて臨みました。
（ChatGPTにそうした方が良いと言われたので…。この参加の仕方がけっこう重要かもです！）
自分用にメモとして纏めています。参考になればさいわいです。

2023/6/22参加レポートは下記に纏めています。

AWS Dev Day 2023 Tokyo 参加レポート（AI、コンテナ、サーバーレス中心）

セッションレポート

セッションレポート

[GS-1-1] Invent and Simplify – クラウドとAIを活用したソフトウェア開発の未来

セッション概要

2006 年にAWS がサービスを開始し、オンデマンドでコンピュートリソースが利用できるようになったことで、ソフトウェア開発は大きく変化しました。その後、開発者はその変化を生かしてさまざまなサービスやソリューション、プラクティスを生み出してきました。そして、2023年現在、生成系AI によってまた大きな変化を迎えようとしています。このセッションでは、ソフトウェア開発の世界的なトレンドを確認し、このような変化が速く、認知的負荷が増大していく環境で、AWS がどのように開発者の方が本来集中すべき領域に注力するのをサポートしようとしているのかお話しします。

講演内容メモ

生成AIが電子レンジにおけるポップコーンの役割になっている
→電子レンジも最初は何に使われているのか理解されていなかったが、ポップコーンを食べるための機械として爆発的に広まった。
現時点でも10万以上のお客様がAWS for MLを使用している
開発ライフサイクルと人工知能
- 開発時
  - CodeWhisperer：コード候補を生成するAI
  - CodeGuru：コードのセキュリティ関連の問題を自動検出
- ビルド、テスト、デプロイ時
  - CodeGuruReviewer：コードレビューの自動化
  - CodeGuruSecurity
  - CodeCatalyst：フルマネージドのCI/CD実現ツール（6/23にハンズオン参加しましたので詳細はそちら参照）
- 運用監視
  - DevOpsGuru
早く安全に
- AWSは年に1億５千万回の本番環境へのデプロイを行っている。
- （厳しいセキュリティ要件を守りながら）
- どうやって？→Infra管理（DevOpsエンジニア）とコード開発（Developper）は一人の人がすべて対応した方が早くて安全。
- AWSのオブザーバビリティ（監視、ログ管理）にはCloudWatchLensやGrafanaを利用

[GS-1-2]『質とスピード』特別編 ? 現代のソフトウェア開発にキャッチアップしていくヒント

講演内容メモ

保守性とスピードはトレードオフではない
ソフトウェア品質モデル：SQuaRE
利用品質
外部品質
内部品質←納期が迫るとここが犠牲にされがち（ステークホルダーが少ない）　※保守性などのこと

テストの自動化の損益分岐点は「４回」、「１か月」以内に現れる（by マーティンファウラー）
（４回で手動テストと自動テストのコストが逆転する）

特殊な業務は当てはまらない？
→業種、規模関わらず当てはまる。

コードの質を高めるには設計から運用まですべてを担当する。（ダメな設計が運用に与える影響を実感することでレベルが上がる）

【IM-1】ZOZOTOWN の大規模刷新から見るマイクロサービス戦略と会員基盤の再実装

セッション概要

ZOZOTOWNではシステムリプレイスに取り組んでいます。現在モノリシックだったシステムからマイクロサービス化が進み、複数のサービスが立ち上がっています。今回は会員基盤にフォーカスしてマイクロサービス化の事例を紹介します。会員基盤では、会員登録や変更、削除をGoでAPI化し、ダウンタイムなしでオンプレSQL ServerからAurora MySQLへデータ移行しました。リプレイスを進めるにあたりAPIのガイドラインも整備しました。マイクロサービス化の流れも含めて具体的な内容をお伝えします。

登壇者

株式会社ZOZO
技術本部 VPoE/本部長
瀬尾直利氏

2019年SREスペシャリストとして株式会社ZOZOテクノロジーズ（現株式会社ZOZO）に入社。2022年4月よりVPoE（Vice President of Engineer：新技術の選定や、優れたアーキテクチャの検討、DevOpsのアプローチなどを自ら率先して提案する役割）に就任。現在は、技術本部本部長兼VPoEとして全社のエンジニア組織開発やZOZOTOWNリプレイスプロジェクトを推進。社外活動として、Rubyのコミッターを務める。

株式会社ZOZO
ブロック長（リーダー）
鶴見純一氏

2016年に株式会社スタートトゥデイ工務店（現株式会社ZOZO）入社。ZOZOTOWNのマイクロサービス化を進めるためにAPI Gateway、ID基盤、会員基盤と複数のサービスの立ち上げからリリースまで行う。現在は会員基盤のリーダーとして、会員マイクロサービスの運用・改善に取り組んでいる。

要約

zozoのシステムをクラウド化してモノリスからマイクロサービス化した話。
マイクロサービス化の目的は並列開発できること。
参考にしようと思ったことは２つ
・開発ガイドラインの整備
・良く使う機能の共通化

講演内容メモ

・zozoサイトについて
　2004年当初の構成はWindowsServer、VBScript＋SQLServer
　2017年までそのままの構成

・移行方針
　・クラウド化
　　スケールのメリットを得る
　　
　・マイクロサービス化
　　案件の並列化が目的
　　
　・脱VBScript
　　JAVA、GO言語にリプレイス
　　
　ストラングラーパターンで移行中。
　（認証機能、商品機能、検索機能、会員機能などがあるが、一つずつ移行していく）

・会員基盤のリプレースの進め方
　会員基盤を構築し、並行稼働中（DBダブルライト）
　DBはSQLServerからMySQLに移行、Webサーバー機能はEKSに載せた。

　・現行調査
　　移行範囲を決める。（利用していないテーブルは移行対象外とする、関連のプログラムを確定）

　・設計・フロー
　　テーブルの分割（会員テーブルを退会会員テーブルに分ける）
　　★開発ガイドライン整備（各マイクロサービスのテックリードが集まって作成）　ガイドラインは不安を取りのぞくガードレール的な役割。
　　→コーディングルールを作る
　
　・開発（API）
　　GOで開発。ヘキサゴナルアーキテクチャを採用。
　　★ZOZOマイクロサービスSDKを開発（良く使う機能を標準化）
　　
　・テスト
　　アプリ、インフラ（SRE）、テストチームで実施。
　　
　・データ移行
　　サービス影響でないように一時DBを用意して実施。

【IM-1】ZOZOTOWN の大規模刷新から見るマイクロサービス戦略と会員基盤の再実装

セッション概要

登壇者

株式会社ZOZO
技術本部 VPoE/本部長
瀬尾直利氏

株式会社ZOZO
ブロック長（リーダー）
鶴見純一氏

要約

zozoのシステムをクラウド化してモノリスからマイクロサービス化した話。
マイクロサービス化の目的は並列開発できること。
参考にしようと思ったことは２つ（★）
・開発ガイドラインの整備
・良く使う機能の共通化

講演内容メモ

・zozoサイトについて
　2004年当初の構成はWindowsServer、VBScript＋SQLServer
　2017年までそのままの構成

・会員基盤のリプレースの進め方
　会員基盤を構築し、並行稼働中（DBダブルライト）
　DBはSQLServerからMySQLに移行、Webサーバー機能はEKSに載せた。

　・現行調査
　　移行範囲を決める。（利用していないテーブルは移行対象外とする、関連のプログラムを確定）

質問

　アーキ選定理由（なぜEKSを選んだのか）は？
　→移行方式中心のご説明だったため、このあたりの説明はなかった。
　マイクロサービス化を行うにあたり一番大変だったことは？やりたいっていう意志だけでやってよいもの？
　→文化が変わるため、ルールの整備に気をつかわないといけない部分が最も大変なように感じた。

ブース巡り

CircleCI

機能としてはCodeシリーズと同じ
YAMLで定義を書く
メリットは監査ログが詳細に出せること
Cloud版とオンプレ版ある。プライベートネットワーク環境ならオンプレ版を利用。
GitはGithub指定。Githubもプライベートネットワーク版があるとのこと。

Okta

ADと連携して認証情報を腹持ちする仕様。
SaaSのため、プライベートネットワークとの連携は不可。

【IM-2】マイクロサービス時代のセルフサービスデータレイク基盤の作り方

セッション概要

マイクロサービスアーキテクチャの採用によってドメイン毎に独立して開発が進められる様になる一方で、データは急速に分散、多様化しています。データに基づいた迅速な経営判断や、サービスへのデータ利用には、正確性と鮮度が重要です。日々変化し続けるマイクロサービスに散らばったデータを効率よく収集し利用可能にするデータ基盤を、小規模なチームで構築・運用する際の課題や実装事例についてお話しします。

登壇者

PayPay株式会社
Principal Software Engineer（自身の専門分野で長年にわたり経験を重ねてきたエンジニアが就く役職）
冨田俊大氏

電力・交通・証券などのバックエンド開発を経て、2013年よりモバイル決済サービス業界に。PayPay入社後は、決済、キャッシュバック、クーポン、データ基盤などに携わり、今は金融サービスの開発をしています。スマホ１つでお金に関わることが完結する社会を作りたいバックエンドエンジニアです。

要約

データレイクの基礎とデータパイプラインをセルフサービス化した話。
セルフサービス化したことで運用が0になったというのがすごい！！
（障害検知から自動復旧まで含めて自動化）

セルフサービス化と聞くとServiceCatalogを連想してしまうが、
Terraformをモジュール化してパラメータを抽象化することでも実現できる。
（IaC管理できるからServiceCatalogより良いと感じた）
Terraformで全てを管理できるようにサーバーレス化する必要があることもポイント。

講演内容メモ

・データレイクの用途
　用途によって、精度と鮮度の要件が変わる。
　社内レポート　集計レベル　30分以内
　取引明細　　　レコードレベル　6時間以内
　サービス利用　MLトレーニング

　数ペタバイト規模になる

・これまでのチーム状況
　マイクロサービスは機能ごとの開発チーム体制
　データ基盤チームは各チームからの依頼を一手に引き受ける形（優先順位がつけられないのも問題）
　
・改善のための施策
　各チームが独立して動けるように
　品質・スピードは落とさない
　→セルフサービス化（マイクロサービス、イベント駆動開発、DevOps、GitOps）する

・セルフサービス
　変更管理、承認プロセス、権限制御が必要
　GitOpsとしてTerraformで管理できるようにサーバーレス化（ジョブはEventBridge利用、Glueなど）
　Terraform入力パラメータの抽象化
　CIツールとしてAtlantisを利用
　
・Terraformルール
　リソース隠ぺい、パラメータ公開、メタデータ入力の必須化（どのチームがどのサービスに使っているのかわかるように）

・自立したライフサイクル管理
　さまざま運用作業があり、それらをすべて自動化しないとセルフサービス化は難しい。
　→StepFunctionsで自動化（同時起動制御はできないため、Lambdaで制御）

・セルフサービス化の効果
　・データパイプラインの初期設定のリードタイム減少　1週間→5分
　・データ差分検知時のリカバリのリードタイム減少
　・Glue採用によりEMR管理不要に
　・構成管理をGitOps化により品質向上

　データ基盤チームは運用100%だったのが開発100%にリソース集中できるようになった。

質問：

Terraformの入力パラメータを抽象化するのはどうやってやったのか？
→★Terraformモジュール化によって対応
　→これならServiceCatalogいらないかも（ルール化とマニュアル化でいけそう）
　　サーバーレスでないとTerraform管理できずセルフサービス化が難しい

【SA-3-1】The anti pattern (ジ・アンチパターン)

セッション概要

SaaSプロダクトをAWSで運用して早十数年。おかげさまでプロダクトは国内シェアNO1【*】にまで成長しましたが、その陰でアーキテクチャ設計や運用面で大小さまざまな失敗を経験しました。
今でこそ笑ってしまうような失敗談の数々。しかし、失敗にこそ学びがある（はず）。笑って聞いてください!

Auroraデータベース作りすぎて失敗した件(マルチテナント戦略)
ELB作りすぎた件(数十のELBと数千件証明書を管理)
VPC切りすぎて失敗した件(多層防御実装を間違えて)
【*広告効果測定プラットフォーム「アドエビス」: 日本マーケティングリサーチ機構調べ　調査概要：2021年6月期_指定領域における競合調査】

登壇者

株式会社イルグルム
開発本部基盤開発部部長
上原賢也氏
2006年　日本発ECオープンプラットフォーム「EC-CUBE」の開発・ローンチ
2009年　広告運用「THREe」のインフラ基盤の設計・構築
2012年　全社の品質管理・インフラの導入・運用をメインで実施
2015年　ベトナム子会社へ出向し、オフショア開発拠点の立ち上げ
2019年～日本に帰国し、主にインフラ面から基盤戦略全般を担当
コスト最適化大好き人間。開発～品質管理～オフショア開発拠点の立ち上げとなんでもやってます。

株式会社イルグルム
山本瑛治氏
“2020年岡山大学大学院自然科学研究科電子情報システム工学専攻卒業2020年株式会社イルグルム入社。以後、インフラエンジニアとして業務に従事。オンプレ、クラウド問わずインフラの設計、構築、運用等を担当。好きなAWSサービス：Amazon S3”

講演内容メモ

アンチパターン紹介

１．よく検討しとけよパターン
・Auroraの中にテーブル作りすぎパターン
　運用後しばらくしたらAutoVacuumが終わらなくなり、ReadIOPSが急増
　Auroraは自動拡張なのでサービス影響は出なかったが、コスト面で問題に。
　手動で定期的にVacuum処理を行うことで対処。。
　
２．アンチパターン許容したつもりパターン
　ELB作りすぎ問題（ELB40台→EC2７台）
　ドメインを分けたいという理由でELBを増やした
　
　KeepAliveが原因でEC2のメモリ負荷影響が大きくなった。
　→KeepAliveオフにした
　　→

３．W-Aの解釈間違えてるよパターン
　基本設計にAWSのWell-Archを意識
　マイクロサービスアーキテクチャに変更
　VPCをサービスごとに分ける方針とした
　→VPCエンドポイントやTGWが増えて費用が増大する結果に。。
　　→これ以上VPCは分けない方針に。。
　　　→正解が分からない。

【SA-3-2】成長を続ける SaaS の AWS コスト管理において開発者としてできること

セッション概要

運営しているSaaSが成長を続けると、継続したコスト管理が重要になってきます。マイクロサービス化が進み、開発者自身でAWSリソースを作成し、運用するということも多くなると思います。自分のチームで利用しているAWSコストの管理できていますか？AWS管理担当者に丸投げしていませんか？開発者にだってできることや気をつけておくべきことがあります。このセッションではChatworkで実践しているコスト管理方法や、開発者が気をつけるべきポイントについて説明します。

登壇者

Chatwork株式会社
SRE部マネージャー
佐々木真也氏
クラウドインテグレータや、AI系スタートアップ等を経験し、2020年にChatworkにジョイン。現在はSRE部のマネージャー。EKSを中心とした実行基盤の改善や、信頼性の向上に取り組む。

要約

マイクロサービス化したらサービスごとにAWSのコストを把握できる必要がある。
（どのサービスがコスト異常か調査するため）
コスト配分タグ必須！！

講演内容メモ

ChatWorkは右肩上がり
SaaSの成長に伴いコスト管理がより重要に

・ユニットメトリクス
　ビジネス指標に対するAWSコストの高さを判断する指標
　ユニットメトリクス増加がみられたタイミングで改善アクションをおこす
　
・マイクロサービスのコスト管理
　DynamoDBの費用が上がっている→どのチーム（マイクロサービス）かわからない
　→このテーブルの費用が上がっている→どのチームかわかる
　ECRのようなリポジトリ単位のメトリクスがないサービスは原因分析に時間がかかる。
　
・コストチェック運用
　CostExproreやAnomalyDetectionを利用
　→コスト配分タグは必須
　★TerraformならDefaultTagsを利用することで全リソースに一括タグ付与が可能
　CI/CD（Atlantis＋Conftest）でタグつけ漏れを防ぐ
　
・リソース作成時のコスト見積もり
　★InfracostはTerraformのtfファイルからコストを試算してくれる
　　VSCodeのExtensionもある

【SA-4-1】初挑戦！コンテナを用いた、建設 SaaS でのサービス品質向上への道

セッション概要

本セッションでは、建設現場における省人化や省時間化を実現する建設現場向けソリューション「SPIDERPLUS」をどのようにSaaS化したのかをお話します。コンテナを用いたアーキテクチャを採用することは当社にとっては新しい挑戦ではありましたが、それにより運用効率の向上と開発スピードの向上を実現しました。コンテナ化における課題や解決策などを技術的な側面からお話し、今後のSPIDERPLUSの展望についても紹介させて頂きます。

登壇者

スパイダープラス株式会社
プロダクトグループ／技術開発部 GM
紙岡保氏

工業学校卒業後、建設コンサルティング会社に就職。組み込み開発経験後、ACCESSに入社。自社製品開発や開発部門長を務め、グループ会社の代表取締役に就任。その後は、独立系コンサルティングファームに転職し、現在は、建設DXを推進するスパイダープラス株式会社でプロダクト開発組織のマネジメントをしている。

講演内容メモ

・SpidetPlusについて
建設DX：建設業務をIPADで管理できるように
1600社、6万IDで利用されている

・DXトレンド
雇用時間関連の法適用を2024年に控え、AI、ドローンなど機械化が進む

・当初の構成
　お客様ごとにサーバーを提供（シングルテナント）
　
　利用開始までのリードタイム、デプロイ時間、NASへのリソース集中が課題に
　→AWS利用し、S3やコンテナ化を検討
　
　Fargateはメモリ16GB必要だったため、コスト見合わず。ECS on EC2を選定

質問

コンテナ化を採用した要因は？
→即時性を得たいため

【SA-4-2】AWS App Runner x AWS Batch を活用した AI SaaS の新規事業開発基盤

セッション概要

新規事業の開発フェーズでは頻繁にコードの変更が行われます。また、AI を活用したサービスでは、アプリケーションの実行基盤の他にAIの実行基盤が存在します。コンテナ技術やCI/CD を用いて、ビジネスの変化に合わせて複数の環境を迅速に更新する必要があります。
App Runner と AWS Batch を活用することで、 AI SaaS の新規事業を高速に検証するためのアーキテクチャを紹介します。

株式会社グリッド
プロダクト開発部 CTO
沼尻匠氏
東京工業大学大学院物理情報システム専攻卒業。製鉄システムインテグレーターにて、インフラ環境構築を担当。グリッドのAI事業立ち上げ時より、AI 開発プラットフォームの開発をリード。最適化PJ にいち早く参入し、グリッドの社会インフラにおける最適化の取り組みの礎を築く。2020 年よりは CTO として、グリッドの技術開発を牽引する。

要約

AppRunnerは仮説検証用で使う程度としていることが分かった。
（今の現場でも言われているが、やはり本番利用は難しい？？）

講演内容メモ

・事業内容
　計画を立案するAIの開発
　インフラ業界の計画（電力、配船計画）
　
・RenomApps構成要素
　アプリケーション：S3、ECS、Aurora
　コンピューティング：AWS Batch
　
・MVP開発（ミニマム開発）
　仮説検証のデモ環境としてAppRunnerを利用
　GitLabであったため、ECRで発火してデプロイ
　GitLab CIでECRへのイメージプッシュを自動化することにより、Gitプッシュからアプリデプロイまでの自動化を実現

質問

Sagemakerは利用しているか？していなければその理由。
→SageMakerの話はでなかったので、利用はしていない。なぜかは分からなかった。

【C-5】Amazon ECS デプロイツール ecspresso 開発 5 年の歩み

セッション概要

Amazon ECS のデプロイツールである ecspresso は、Go で作られた OSSです。2017年に開発が始まり、2023 年まで継続的に機能追加やバージョンアップを繰り返してきました。今では多くの国内企業でも利用されています。
https://github.com/kayac/ecspresso
このセッションでは、AWS SDK を利用した Go による CLI ツールを 5 年以上継続的に開発してきた経験から得た知見をお伝えします。

登壇者

面白法人カヤック
技術部 SREチームリーダー
藤原俊一郎氏

2011年より面白法人カヤック。SREチームリーダー。主にソーシャルゲーム、自社サービスを担当。 ISUCON優勝4回、出題3回。最近の趣味はマネージドサービスの隙間を埋める隙間家具のようなツールをGoで作ってOSSにすること。

講演内容メモ

・ecspressoとは
タスク定義とサービスを管理
Copilotも同様な機能だが、そちらはVPCなどのリソースも管理できる
ロールバックできることがメリット
8/8 JAWS コンテナ支部でECSPRESSO

・設計思想
　・タスク定義とサービス管理に特化
　　他のリソースとライフサイクルが違うから
　　扱う担当が違う（VPCはインフラ、コンテナはアプリ）
　・ECS専用ツール
　　
・ecspresso init
　設定ファイル自動作成。簡単に手動作成したECSをIaC管理にできる

・ecspresso exec
　ECS Execを利用可能に

質問

どのような場合にecspressoは採用されるもの？
→ロールバックできることがメリット（当初はそんな機能がECSになかった）