AWS DevDay 2023 参加メモ

先週6月20日・21日 AWS Dev Day 2023 Tokyo に参加しました。2日間のイベントでしたが、業務として参加し、学んだことや気づきなどをまとめた個人メモです。

DAY 1

• 【GS-1】DAY 1 ゼネラルセッション：

  • CodeCatalystシリーズにおいて、新しい機能の発表がまもなく行われる予定です。
  • CodeWhispererなどのAIを活用したツールを使用することで、開発効率を向上させることができます。
  • 和田さんの話
    • 質とスピードはトレードオフではありません。
    • テストなしで開発を進めることは一時的には早く感じるかもしれませんが、結果的に手戻りが生じることがあります。
    • 良いコードは時間をかければ必ずしも書けるわけではありません。良いコードを書く人は短い時間でも良いコードを書くことができますし、逆に時間を与えても良いコードを書けない場合もあります。
    • 納品日を守る必要がある場合、スコープを減らすことが良い選択です。

• 【C-1】モノリシック Lambda の何が悪い！ モノリスファーストなサーバーレス開発：

  • Lambdaの歴史について学びました。S3にアップロードされたオブジェクトをEventで受け取り、処理するために開発されたもののようです。
  • invokeAPIもEventDrivenのアーキテクチャであります。
  • Snapstartは現時点ではJavaとCorrettoにのみ対応しています。他の言語についても、リクエストに応じて対応を優先的に決定しているようです。

• 【B-2】BLEA開発チームが学んだAWS CDKの開発プラクティス（2023年版）

  • BLEAとはBaseline Environment on AWSの頭文字です。
    • セキュリティベースラインをコードで提供します。
    • CI/CDのサンプルを提供します。
  • セキュリティの役割が変わりつつあり、GatekeeperからGuardrailへと移行しています。
  • BELA v3では原則的に1つのcdkAppにつき1つのスタックで構成するようにしています。スタックを分けずにコンストラクトを利用する構造にし、ファイルを分割しています。
  • シングルスタック化により、デプロイ時間を50%以上短縮することができました。
  • 詳細な命名ルールを統一するための修正が必要です。
    • ConstructIDはPascalCaseを使用します。
    • シンプルかつ短い名前を使用します。
    • 共通のプレフィックスは付けません。
    • StageのConstructIDには環境名を利用します。
    • StackのConstructIDにはサービスの名前を利用します。
    • ResourceのConstructIDにはシンプルな名前を利用します。
  • 環境ごとのパラメータ変更方法：
    • パラメータを読み込んで渡す方法
    • スタックを環境ごとに定義する方法
  • IaCのビルダーが加速させることがわかりました。

• 【B-3】やはりポリシー...!! ポリシーは全てを解決する...!! OPAで始める Policy as Code

  • オープンソースの OPA について語っていました。Policy as Code についてもっと調べるきっかけになりました。

• 【B-4-1】 アジャイル開発は本当に必要なのか、何を解決するのか

  • アジャイル開発という開発手法は存在しなく、アジャイルというのは状態です。
  • 従来の方法と同じようにドキュメントを作成しますが、変化に柔軟に対応することが重要です。
  • アジャイルは目標達成もしくは時間的な制約によって解散されます。つまり、成果を出せずに解散することもあります。
  • アジャイルの過程は以下のようになります: Forming→Storming→Norming→Performing→Adjourning
  • 本来のアジャイルと現実のアジャイルには差があります。現実のアジャイルも従来型と近いです。
  • ソースの行数やスクラムのストーリーポイントでは生産性を測ることはできません。
  • 生産性を上げるためには組織文化の変革が必要です。例えば、deployの承認に時間がかかることがあります。

• 【B-4-2】 エンジニアとしての自分とマネージャーとしての自分の狭間で、どう成長していくのか？

  • 組織を大きくするにはマネージャーが自分のアウトプットよりもチームのアウトプットを大きくする必要があります。
  • 丸投げもマイクロマネジメントもチームの成長には良くありません。
  • 結果責任と実行責任はマネージャーとメンバーを区別する必要があります。

• 【B-5】コードレビュー辛くないですか？その原因と対策を考える

  • コードレビューはする側もされる側も大変な作業であることは納得できました。
  • レビューする側の言葉使いや指摘方法によって、レビューされる側のモチベーションにも影響することが印象的でした
  • コードレビューの目的は、コードの品質を高めるだけでなく、チーム内での知識共有や学習の場でもあることです。

DAY 2

• 【GS-2】Day 2 ゼネラルセッション:

  • 進化する技術への追従に不安を感じ、時に落ち込むこともあります。しかし、コミュニティに参加し意見を交換し、学びながら乗り越えることができます。
  • 睡眠や休憩、外出、テックイベントやミートアップへの参加は重要です。
  • 自分の理想とする人物をメンターにし、挑戦することで成果を上げることができるかもしれません。
  • ChatGptなどの大規模言語モデル（LLM）については知識が不足していることがわかりましたので、今後学習していきたいと思います。

• 【E-1】モダンアプリケーションにおける分散トランザクションの動機と実装パターン:

  • デプロイの独立性については、コード単位や開発プロセス単位、リソース単位での分離が可能です。
  • デプロイの独立性により、チームの自律性が高まり、スピーディな開発が可能となります。
  • ビジネスドメインごとにマイクロサービス化することが推奨されています。
  • 複数のマイクロサービスが同一のデータレイヤーを共有することは望ましくありません。
  • Consistency ModelやSagaパターンについての話題もありました。フルマネージドなサービスであるAWS Step Functionsを使用することで、オーケストレーションが容易になります。

• 【GT-2】イラストで学ぶAmazon DynamoDB ～テーブル設計からパフォーマンスチューニングまで～:

  • ゲーム開発におけるDynamoDBの活用方法についての話題がありました。
  • コストの予測は難しいですが、初めはOn-Demandで開始し、数ヶ月のメトリクスを分析した後にProvisionedに移行することが推奨されています。
  • テーブルを複数作成する代わりに、1つのテーブルでデータを管理することもコストの面でも有益です。

• 【E-3】実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで:

  • 無理にマイクロサービス化する必要はないという話について、よく理解しました。
  • ドメインエキスパートと開発者が協力してコンテキストとモデルを作成することが重要です。
  • モノリスから直接的にマイクロサービスへの切り替えではなく、ストラングラーパターンを使用してリスクを軽減することが良い方法です。

• 【F-4-1】家で楽しむIoT:

  • IoTに興味がある場合、2~3万円程度で簡単なシステムを自宅で作って楽しむことができることについての話題でした。
  • ネコの健康管理のための体重測定のIoTシステムの事例も紹介されました。
  • 機能面で優れたシステムを作ることは容易ではありませんが、趣味として楽しみながら学習することで、身近なサービスを作成することができると感じました。

• 【E-4-2】既存のWeb向け課金システムをそのままに、Sagaパターンでのアプリ内課金システム構築:

  • 朝日新聞デジタルの課金システムをSagaパターンでどのように実装したかについての紹介がありました。
  • Sagaパターンについての知識が少なかったため、今後勉強していく予定です。

• 【E-5】第一回 似てるサービス使い分け大会:

  • AWSが提供する似ているサービスの使用ケースについての話題でした。説明には時間がかかるため、より深く理解するためには後で調査する必要があります。