お昼の時点で参加人数1,500人を超えていたこともあって、200人収容できるセッションでも立ち見が出るほどの盛況っぷりなのが印象的。忘れないように会場で実際に聞いてきたセッションについて簡単にまとめておきます。サーバレスで動かすトークン発行プラットフォームjawsdays2019.jaws-ug.jp実際にトークン発行プラットフォームとして使っているEtheriumすごい的な話ではなく、如何に新しい技術を使って日々新しいものを作るかの過程の話だった。新しいものを使うことはリスクになる上に、人・時間・知識がない中で最小限のプロダクトを作ってしまおう。サーバーレスは良いソリューションになるんだってのがこのセッションでの学び。Serverlessを活用したサービス監視slide.seike460.comサーバーレスを使いつつ、監視コンポーネントとAWSのサービスの組み合わせをラップしたOSSを作った話。内容を踏まえて、監視に必要な要素を明確にしながら自分でOSSを作ってしまおうというところがすごい。Gatewayから直接Lambdaを叩かずSQSを間に挟んでいること。監視エージェントとストレージを疎結合にするための戦略なのは勉強になった。LogsにLambdaのサブスクリプション貼る時と同じことになるもんね。GatewayがLambda以外のサービスに直接リクエストできるのも初めて知った。Soudai)のRDBリファクタリングのセッション。DBの寿命はアプリよりも長い。アプリが動いて数年経つと、謎テーブルの存在ややカラムに意図しない値、制約が貼ってない等々技術的な負債が貯まってくる。そんな状況でRDBをリファクタリングされた時(現在進行形らしいですが)の挑戦記録を話されていました。2ステップ大きく分けてされていたようで、どちらのステップも興味深い。MySQL5.6で運用しているテーブルをリファクタリングするために、トリガー(SQLが発行されたイベントに反応して実行される処理)を使う。RDSにマイグレーションする。流れでマイグレーションしたと。参照はAPI経由でいきなり新しいスキーマのPostgreSQLから実施することでModel単位に移行させるといったことは今後の業務で使えそうなTipsです。興味深かったのが、実運用のところ。平気で20~30秒(?)マイグレーションが遅延する、更新が激しいとDMSが単一障害点になってしまうといった使ってわかったデメリットなんだとか。最後にそーだいさんが言っていたように、RDBリファクタリングは「覚悟」が必要とのこと。AWSからメール送るならSendGrid一択ですよねjawsdays2019.jaws-ug.jp自宅から歩ける範囲に平日にSendGridの勉強会をやっているのは知っていたけど、なかなか行けなかたので参加。ランチタイムの15分セッション。SendGridそのもののアピールがほとんどでしたが、SESとSendGridの比較が乗ってて確実にメールを届けるなら良い選択肢だと認識。クラウド時代のモニタリングといえばDatadogだよねjawsdays2019.jaws-ug.jpAWSだけでなく、一元的にモニタリング・メトリクス・ログ・APM収集できるのを再確認。2018のre:Inventで一番デカイブースを構えていたとのことだったので、ちょっと興味が湧いたな。可愛いDatadogのステッカー貰えたし、使ってみようかしら。Mackerel、ElasticSearch/Kibanaと比較して要検討。ファーストアプリよりも先にまずはCI/CDパイプラインを作ることを強調。一発目のデプロイからアプリは雛形でいいからパイプラインでデプロイを書けることが、ROIの高い投資だと表現していた。IoTセキュリティとAWSセキュリティ」jawsdays2019.jaws-ug.jpF-Secureというセキュリティソフト・コンサルティング会社の営業さんがスピーカーのセッション。なんとLT3本立てという豪華な構成に加えて、話がめちゃくちゃうまかった。会社の事業紹介しつつAWSを使いながらセキュリティサービスをどう提供しているかというお堅い感じのサービスにも関わらず新鮮なトークでした。ユーザーがアンチウイルスソフトの利用登録とアクティベーションを可能な限り早く行うため、かつユーザーを逃さないようにサーバーレスにしたとのこと。Lambdaの組み合わせで実現しているのが面白い。Codeに疲れたので、僕たちが本来やりたかったことを整理するspeakerdeck.com個人的に一番登壇者の苦労に共感できたセッション。(会場の人の反応を見る限り大多数が同じような悩み・つらみを抱えていそう)リソース管理のためにTerraFormテンプレートを書いてたけど、本当はそこにばかり時間をかけている場合じゃなくて価値あるタスクをするべきなのに辛さばかり目立つという話。Eventsのルールを作れないとこでハマってたので、ただただ共感でした。Codeで管理すべきこととすべきではない(割りに合わない)ことを考えましょうという点でしょう。ROIが低いならWebコンソールやCLIからでええやんとのことでしたが、私が考えている答えとしてはほぼ同じです。本番環境でも使うサービスなら失敗してもロールバックできるように出来る限りCLIがベターかなとは思います。CLI支部の方のセッション。APIの働きを理解することである。APIのほとんどを操作できるのだから、CLIで操作することこそAWSを真に理解するための道であると説いていたのが印象的。確かに本番環境でGUIをいじるのは流石にないけど、CloudFormationで時間かけて無駄に長いスタックのYAML書くよりもCLI書いて直接操作するのが直感的だ。何はともあれ、公式リファレンスを読もう。CLI支部の勉強会開催場所は会社のすぐそばだし行こうかしら。上記以外にもEKSやDevSecOps/テスト自動化のセッションと懇親会の時のLTも聞きたかったけど、時間が被って断念。SlideShareやSpeakersDeck、Twitterに資料が上がることを期待します。セッション以外も嬉しかったポイントがあって、広い会場でも確実にスピーカーの声が聞こえるように一人一人スピーカーホンが配られてたのはGJだった。隣のセッションとはパーティション一枚でしか区切られてなかったから、結構声が隣から漏れてきてたし。あとはお弁当豪華でしたね。テーマなだけありました。