🥳

AWS Dev Day 2023に参加してみた！①

2023/06/24に公開

AWS

AWS Dev Day 2023に参加したのでその様子をお伝えします！参加したセッションの内容についても簡単に紹介します。

会場の雰囲気

会場はベルサール渋谷ガーデンというところです。渋谷駅から徒歩15分の所にあります。
会場の構図は、Summitと似ています。

スポンサー企業の展示ブースもあります。

自分が登録したセミナー

今回自分は以下のセミナーに参加しました。

1日目

モノリシック Lambda の何が悪い！モノリスファーストなサーバーレス開発

概要

Lambdaを使用する際に、Lambda=マイクロサービスでなければいけないのか？そのそもLambdaにおけるマイクロサービスの定義とは？といった内容について紹介したセッションです。

以下は内容の抜粋です。

API Gatewayとの統合においてパスやリクエストの種類ごとに違う関数にルーティングされる構成は煩雑であり、関数の数が増大する要因となる

greedyパス変数で一度すべてのパスリソースを取得し、リクエストやパスの制御は関数内で行えばモノリシックな関数で対応することが出来る

Lambdaはオートスケーリングするので、自分でマルチプロセス/スレッドの処理を実装する必要はない
- マルチプロセス/スレッドはスケールアップに該当する処理であり、スケールアウトするLambdaとは相いれない

FaaSとコンテナではマイクロサービスの粒度が違う
- どのドメインの単位で関数を分割するかを考える必要がある
- 1機能＝1関数とすると、関数が1000を超える場合もあり、管理が複雑になる
- モノリシックだと思っているLambdaの構成が、既にLambdaのスケールではマイクロサービスになっている場合がある

感想

こういった内容を聞く度に、マイクロサービスって管理が半端なく大変そうだなーといつも思ってます。関数1000個とか想像がつかない..
他にも色々な話が合ったのですが、自分は趣味でLambda触ったことがある程度だったので、かなり難しい内容に感じました。マイクロサービスを実装するアーキテクチャにはECSやEKS上でコンテナを使う場合と大量のLambdaを用意する場合があると思いますが、Lambdaはコンテナよりも細かい粒度で作成可能な分、どういった単位で関数を分割するのかを決めるのがやや大変そうに思いました。

BLEA開発チームが学んだAWS CDKの開発プラクティス 2023年版

概要

BLEAテンプレートを使用するとどう開発のアジリティが上がるのかや、BLEAテンプレートで使われているAWS CDKでのIaCのベストプラクティスについて紹介したセッションです。

BLEAテンプレートの概要は以下のような感じです。

開発者はセキュリティについて考えるよりも、開発業務に集中したい
だが、中央集権側の管理では開発のアジリティが低下する
BLEAテンプレートは開発時のセキュリティのガードレールのような役割を果たし、その範囲内での自由な開発を促進する
BLEAテンプレートはAWS CDKで実装されているIaCのテンプレート

また、BLEAテンプレートはいままでバージョン2でしたが、最新バージョンのV3からは以下のような変更点が加わったようです。

V2までは複数のスタックで構成されていたが、V3からは1スタックの構成にすることで、依存関係の解決の必要がなくなった

デプロイ時間が大幅に短縮された（5~60%）

その他、CDKのベストプラクティスとして以下のようなことが述べられていました。

パラメータはcontextパラメータから動的に取得するのではなく、別途用意したインターフェースを実装する形でハードコードするのがベター
- 複数のシェルを開いて並列にデプロイを実行する場合にcdk.outが上書きされることがなくなる
- 環境ごとにアーティファクトを分離する必要がなくなる

反復処理や条件分岐があるとコードの可読性が落ちるため、宣言的な記述を心がける

感想

スタックの分割単位はCDKを使う場合の大きな考慮点の一つでしたが、結局一つも分けない方がいいんかーいとなりました。ですが、よく見るとすべてのリソースを1スタックにぶち込むのではなくて、今まで作っていたスタックの分割単位で新しいconstructを定義するようになっていました。しかし、スタックを分割するかしないかでデプロイ速度が半分以上も変わるのはびっくり...
個人的にCDKは自由度が高い分、考慮事項がかなり他のIaCツールよりも多くなって複雑化している印象です。

リアルタイム運用の成熟度とは？ - PagerDuty AIOpsで実現する運用の自動化と継続的改善

概要

モダンなシステムの運用方法の紹介や、PagerDutyを使用したインシデント対応のデモなどを行ったセッションです。

冒頭では以下のような内容が述べられていました。

昨今は分散システムや業務の分散によりシステムの運用が複雑になっている
運用をモダン化しないと、システム障害に対応できなかったり、エンジニアのモチベ低下になる
そのため、組織の成熟レベルに合わせて運用方法をモダナイズしていく必要がある

PageDutyを使う利点は以下のようです。

少ないリソースで迅速なインシデント対応が可能になる
インシデントを自律的に解決するロジックを組むことが出来る
リアルタイム運用のベストプラクティスを教えてくれる

実際のインシデント対応はWebコンソールかモバイルアプリ上で行うことが可能で、電話、SMS、メールなど様々な方法担当者に通知することも出来るそうです。

また、AWSと連携する際のサンプルアーキテクチャについても紹介されていました。

その他、PagerDutyではインシデント対応のベストプラクティスも公開しているそうです。
私の所属している部署でも最近SREに取り組もうとしているので、ぜひPagerDutyを使ってイケてるインシデント対応をしたいと思いました。

アジャイル開発は本当に必要なのか、何を解決するのか

概要

アジャイル開発の本当のあるべき姿や、それを実現するためのTipsなどについて紹介していました。
以下は講演内容の抜粋です。

アジャイルではドキュメントよりも動くソフトウェアを重視し、計画よりも変化に柔軟に対応することを目指す
アジャイルとは状態を指す概念であり、上記のマインドセットを持っていればいい

アジャイルな状態になるには数か月かかる
形成期、混乱期などがあり、チームとして機能するまでには時間がかかる

プロダクト開発に終わりはない
アジャイル開発では開発者と運用者が同じであるべき
でないと、なんちゃってアジャイル（ウォータースクラムフォール）になってしまう

アジャイルで開発者の生産性を測るのは難しいが、代替となる指標には色々ある

アジャイルとは機能するチームを作るためのものであり、決められた期間に開発する手法ではない
開発生産性を上げるには技術的な部分に加え組織文化の変更が必要
生産性の定義をチームで認識合わせする必要がある

感想

自分のようなウォーターフォール開発がメインの会社で働いている人間には、だいぶ耳の痛い話でした。。。自分たちで一つのサービスを継続して開発・運用し続ける文化が無いのでそこの認識から変えていく必要がありそうです。WBSできっちり納期が決まっている、開発はパートナー利用前提、開発者と運用担当者が分離しているみたいなのはアジャイルのアンチパターンのようですね。SIerでアジャイルが馴染まない理由がよく分かります。このあたりが変わっていくとアジャイルに近づく希望があるかもしれませんね。

まとめ

正直かなりレベルの高い内容も多く自分の知識レベルではついていくのが難しい場面もありましたが、とても勉強になりました！やはり各技術の最新トレンドを追うのは楽しいですね。ぜひここで学んだ知識を実業務にも活かしていきたいところです。二日目に続きます。