AWS Dev Day 2023 Tokyo 参加レポート(2023/6/22分)
はじめに
こんにちは!SHIFTの當眞です。
AWSの開発者向けのイベントAWS Dev Day 2023 Tokyoに参加してきました!
私は主に、AI、コンテナ、サーバーレス、マイクロサービス、CI/CD関連のセッションを受講しています。参加前にイベントサイトに記載のセッション概要から質問・疑問を考えて臨みました。
※2023/6/23分のレポートは下記にまとめています。
セッションレポート
【GS-1】DAY 1 ゼネラルセッション:[GS-1-1] Invent and Simplify - クラウドとAIを活用したソフトウェア開発の未来 /
セッション概要
所感
現在のAIの浸透状況
開発ライフサイクルとAWS人工知能サービスとのかかわりについて
開発プロジェクトにおける各フェーズで利用できるAWSのAIサービス紹介がありました。
参考までに列挙しておきます。
1.開発
CodeWhisperer:コード候補を生成するAI
CodeGuru:コードのセキュリティ関連の問題を自動検出
2.ビルド、テスト、デプロイ
CodeGuruReviewer:コードレビューの自動化
CodeGuruSecurity :静的アプリケーションセキュリティ検査 (SAST) ツール
CodeCatalyst:AWS での計画、開発、配信のライフサイクルを高速化 ※翌日の6/23にハンズオンを受けてみましたが、まだ発展途上のサービスだと感じました。
3.運用監視
DevOpsGuru:運用上の問題が顧客に影響を与える前に、その問題を特定
【IM-1】ZOZOTOWN の大規模刷新から見るマイクロサービス戦略と会員基盤の再実装
セッション概要
登壇者
要約
zozoのシステムをクラウド化してモノリスからマイクロサービス化した話でした。zozoのような大きなシステムであっても2017年まで2004年当初の構成(※)のままだったというのは驚きました。
※2004年当初の構成はWindowsServer、VBScript+SQLServer(当時はベストプラクティスと言われていた構成)
2017年以降のマイクロサービス化の取り組みについての発表でしたが、マイクロサービスの目的はチームに依存せずに並列開発できることが一番大きかったようです。
参考にしようと思ったことは以下2つです。
開発ガイドラインの整備(各マイクロサービスのテックリードが集まって作成)
→開発者の不安や負担を軽減するガードレール的役割になったとのこと(今までとルールが変わるので重要)
良く使う機能の共通化(ZOZOマイクロサービスSDKを開発)
→マイクロサービスであっても共通化して効率化するという考え方は変わらない
質問
アーキ選定理由(なぜEKSを選んだのか)は?
→移行方式中心のご説明だったため、このあたりの説明はなかった。
マイクロサービス化を行うにあたり一番大変だったことは?やりたいっていう意志だけでやってよいもの?
→文化が変わるため、ルールの整備に気をつかわないといけない部分が最も大変なように感じた。
【IM-2】マイクロサービス時代のセルフサービスデータレイク基盤の作り方
セッション概要
登壇者
所感
データレイクの基礎とデータパイプラインをセルフサービス化した話。
セルフサービス化したことでインフラの運用が0(完全にセルフサービス化)になったというのがすごい!!(障害検知から自動復旧まで含めて自動化)
セルフサービス化と聞くとServiceCatalogを連想してしまうが、Terraformをモジュール化してパラメータを抽象化することでも実現できる。(IaC管理できるからServiceCatalogより良いと感じた)
すべてをTerraformで管理できるようにサーバーレス化する必要があることもポイント。
質問:
Terraformの入力パラメータを抽象化するのはどうやってやったのか?
Terraformモジュール化によって対応したとのこと(これなら確かにできるし、案件でルールを決められる。)
しかしサーバーレスでないとTerraform管理できずセルフサービス化が難しい
【SA-3-1】The anti pattern (ジ・アンチパターン)
登壇者
要約
アンチパターン紹介
よく検討しとけよパターン → Auroraの中にテーブル作りすぎ
アンチパターン許容したつもりパターン → ELB作りすぎ問題(ELB40台にEC2が7台)
3.W-Aの解釈間違えてるよパターン
【SA-3-2】成長を続ける SaaS の AWS コスト管理において開発者としてできること
セッション概要
参照: https://speakerdeck.com/taishin/aws-devday-saas-cost
登壇者
要約
マイクロサービス化したらサービスごとにAWSのコストを把握できる必要がある。(どのサービスがコスト異常か調査するため)
コスト配分タグが必須になる。(TerraformならDefaultTagsを利用することで全リソースに一括タグ付与が可能)
【SA-4-2】AWS App Runner x AWS Batch を活用した AI SaaS の新規事業開発基盤
セッション概要
登壇者
要約
AppRunnerはコンテナイメージのプッシュを契機にアプリケーションのデプロイ(=コンテナのCI/CD)を実現するサービス。
AppRunnerはプロトタイプとして仮説検証用で使う程度としていることが分かった。
今の現場でAWSのプロフェッショナルサービスの方にも言われましたが、やはり本番利用は難しいようです。。
(ただ昨今はAppRunnerの機能が拡充してきているので、本番利用の余地が出てきているとの情報もある)
質問
Sagemakerは利用しているか?していなければその理由。
→SageMakerの話はでなかったので、利用はしていない。なぜかは分からなかった。
【C-5】Amazon ECS デプロイツール ecspresso 開発 5 年の歩み
セッション概要
登壇者
所感
ecspressoは登壇者の方が趣味で作ったサービスで、それが多くの国内企業でも利用されるまでに成長したとのこと。
ターゲットをAWSのECSのみにツールの対象を絞ったことで(=マルチクラウド化などには手を出さない)変化の速いAWSサービスについていくことができたというお話が印象的でした。
質問
どのような場合にecspressoは採用されるもの?
→コンテナリリースのロールバックできることがメリット(当初はそんな機能がECSになかった)
おわりに
DevDayはこれまでも2回くらい参加していますが、開発者向けのイベントなのでインフラエンジニアの自分が参加しても何を言っているかわからないことが多かったです。
しかし今回はインフラ関連のセッションが多く、自分でも理解・納得できることが多かったです。
開発者とインフラの垣根がなくなってきているというのは、やはり事実なんだということを突き付けられた感じがしました。「インフラエンジニアが開発知識を知らなくても問題がない時代はそろそろ終わるかもしれない」という危機感を持ってこれからも頑張っていきたいと思います!!
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
PHOTO:UnsplashのDavid Jorre