omuronの備忘録

個人的な備忘録

「JAWS-UG朝会 #56」 #jawsug_asa 受講メモ

AWS 勉強会

JAWS-UG朝会 #56

jawsug-asa.connpass.com

前回は通勤で見れなかったので2ヶ月ぶり！

セッション

セッション① Terraformあれやこれ

emiさん

speakerdeck.com

  • Terraform インストールして AWS CLI のセットアップが必要
  • .tf ファイルを作成
    • Terraform ブロックをまずは作成、terraform のバージョンと provider のバージョンを指定
    • tfstate ファイルの場所を指定
    • provider でリージョンやAWSプロファイル指定
    • resource 実際のリソース作成
      • リソース名が main だったり this だったりするのは CFn でいう論理名
        • this はそのリソースが一つしかなかったり、適切なものがない場合に使う
        • リソース名は同じ名称を繰り返さない！
  • コマンド
    • terraform init 環境準備
    • terraform plan ドライラン
    • terraform apply リソース作成
    • terraform destroy 削除
  • 変数を管理する variables.tf
    • タグ名とかを一括で設定変更できたりする
  • モジュールに切り分けて複数の環境にまとめてデプロイできる
  • Terraform スタイルガイドも参考に
    • コメントには # を使用
    • 複数単語の区切り文字は_を使う
    • 変数（variables）や local の使用は可読性を下げるので多用しない

CloudFormation学んでCDKに移行するように、Terrafomも学んで管理が大変になってくるとCDKTFに移行したりするのかな？
Terraformも裏側でCloudFormation生成していると思ってんですが、AWS CLI使ってるんだ。
ゆえに、CFn の制限でできないこともできたりすることもあるのね。

セッション② 今さら聞けない!? AWSの生成AIサービス Amazon Bedrock入門！

みのるんさん（KDDIアジャイル開発センター）

speakerdeck.com

  • Bedrock：開発者向けの生成AIサービスで、開発者向けにAPIで提供
    • AWSのサービスとして使えるのが便利
    • 現時点で7社25モデルが利用できる
    • テキスト生成はClaude、埋め込みはCohere、画像生成はStable Diffusion / Titan Image Generator がオススメ
    • LangChainにAWS専用パッケージが登場
  • ナレッジベース＆エージェント：高度なAIアプリを複雑なコードを書かずとも簡単に作れる
    • ナレッジベースで社内文書検索のRAGが簡単にできる
    • エージェントで自立型AIエージェントを簡単に作れる
  • Step Functionsと組み合わせてAIアプリをローコードで作れる
  • API叩くだけなので内製開発の入門にもってこい

今朝のアップデート「LangChainにAWS専用パッケージが登場」が盛り込まれてるのがすごい。
あと、本も発売するけどアップデート激しいから、やっぱりギリギリまで校了できないのね。

LT① AmplifyにCDKがやってきた！プレビュー版のAmplify Gen2を触ってみた

NRIネットコム株式会社 髙橋透さん

speakerdeck.com

  • Amplify Gen2
    • TypeScript利用可能で、Gen1のCLI利用からGen2ではCDK形式へ
      • CLIで都度pushしなくていい
    • ホットスワップ可能
      • AWSに即デプロイ可能

CDKみたいにかけるのはいいですね。

LT② SESのDMARCを調べてみた

富松 広太さん

  • DMARC認証
    • SPF認証、SPFアライメント、DKIM認証、DKIMアライメントのいずれか３つを Pass する必要あり
  • SPFアライメント
    • 差出人情報: Envelope-From, Header-From
  • AWS SES で DMARC のレコードを登録する場合は aspf=r に指定する

DMARC 難しいぞ！
とりあえず認証3つ通せばいいのか。

LT③ ブログ投稿することで得た気づき

株式会社エーピーコミュニケーションズ 中嶋さん

  • 記事にしたことは記憶に残る
  • 文章力構成力が身につく
  • 早いタイミングで経験するといい

記事にしても記憶に残らなくて、ググると自分の記事がひっかかり思い出すことがあり、老化を感じますね

「JAWS-UG東京 ランチタイムLT会 #10」 #jawsug_tokyo 受講メモ

AWS 勉強会

JAWS-UG東京 ランチタイムLT会 #10

jawsug.connpass.com

セッション

LT① AWS認定資格を取得したので初めてマネコンを触った時を振り返ってみた。

相川 奈槻さん（三菱電機株式会社）

  • 初めてマネコンを触った時
  • 認定資格を取ったら
    • AWSが怖くなくなった

触って学ぶのは大事だけど高額請求があるからクラウドは怖いで勧められるかは微妙ですよね。
お勉強して知ってから触るのは安全対策としてはいいですね。

LT② API Gatewayと少し仲良くなってみた！

升谷 直緒さん（株式会社エーピーコミュニケーションズ）

  • API Gatewayでスタブ作成
    • Mock 利用ですぐモックができた
    • API キーオンに設定するだけで API キー利用ができた
    • マッピングテンプレート使うだけでパラメータでの応答結果を変えることができた

API Gateway をマネジメントコンソールで触ったことがほとんどないけど、簡単にスタブ作れるんだ。

LT③ データ分析基盤構築に役立つAWSマネージドサービス紹介(Appflow,MWAA,Glue)

樋口 量さん（株式会社NTTデータ）

  • Amazon Appflow：接続設定でデータ抽出できてマッピングもUIでできる
    • 連携元の変更が反映されないので「手動でフィールドをマッピングする」から変更が必要
    • 項目の順序は保証されないのでCSVなどでは注意、JSONだと固定化できる
  • Amazon MWAA：ワークフロー作成サービス
    • 他のPJのDAGが見える、ログが見える
  • AWS Glue：ETLツール
    • 他のPJのJOBが見える、ログが見える

AWS的には違うプロダクトはAWSごと分けろというのがベストプラクティスだからPJやログが混ざるのはしょうがないか？

LT④ API Gatewayを使ってgpt-4からの回答をストリームレスポンスさせる

山口 歩夢さん（KDDIアジャイル開発センター）

  • GPTの回答をバルクレスポンスではなくストリームレスポンスにして体感速度をあげたい
    • stream=True 設定でストリームレスポンスになる
  • REST API だとストリーム的にデータ返却できないので WebSocket API を使う

WebSocket 使うとクライアント増えたときに大変そうだけど APIG+Lambda のサーバレスだとあまり気にしなくていいか。
お金周りは高くなりそう。

LT⑤ 自作モデルをAWS Panoramaで動かしてドローン映像をリアルタイム解析した話

勝田 広樹さん（デロイトトーマツコンサルティング）

  • AWS Panorama：オンプレミスでコンピュータービジョンを提供するサービス、画像認識
    • EdgeにApplianceをいれてSDK使ったアプリを作って実装する
    • 日本リージョン未対応、Panorama Appliance が高い

AWS Panorama初めて見ました。
ドローンで撮影した動画をリアルタイムで画像解析するのは面白そうですね。

「JP_Stripes 大阪 Vol.9 - コードを書かずに始める、売上と収益の可視化や分析方法入門」に参加してきた #JP_Stripes

勉強会

JP_Stripes 大阪 Vol.9 - コードを書かずに始める、売上と収益の可視化や分析方法入門

jpstripes.connpass.com

久しぶりにStripeイベントに参加しました！

セッション

オープニングセッション

Stripe 小島さん

  • RevOps 推し
    • 儲かり続けるための仕組み作りましょう
  • Stripe を通過した決済金額前年比25%増で一兆ドル
  • 手数料は3.6%、クレカ入金は4-5営業日

事例セッション1: SaaS事業をStripeで管理する方法

株式会社INFLU 水戸さん（@go_line38）

  • Lea：Lineのネットショップサービス
    • Lineの売上から5%引いて利用事業者へ支払い
    • クレカ決済は1.4%Stripeに支払い
    • 3,000円/月額利用料
  • 今の数字がわかるか？
    • スタートアップには重要
  • ダッシュボードで見るべき指標
    • MRR, チャーンレート, GMV, 売上, 新規契約数
    • モニターに出して常に見えるように
      • 今の違和感に気づける

Stripeダッシュボードから始めるRevOps

Stripe 岡本さん (Developer Advocate)

www.docswell.com

  • BizとTechを結ぶStripe
  • 海外だと資金調達や資金移動のサービスも展開
  • Bizに役に立つダッシュボード
    • iOS/Androidのモバイル向けアプリも準備
  • Stripe Sigma
    • SQLでStripeのデータを取れる
  • Stripeで解約アンケートと分析も可能
  • クロスセル、アップセル機能あり

LT: Stripeでサブスクリプションに割引を適用したときの注意点

speakerdeck.com

LT Stripe Connectの振込明細にインボイス制度対応をした議事録

兵頭さん

  • Visa/Master と JCB の振込明細が違う
  • Report APIはConnect手数料取得できない

LT

高野さん

  • エンジョイワークス
  • 会社に入るお金を全部Stripeで管理したい

所感

久しぶりの大阪Stripeイベントに参加してきました。

打ち上げでゆっくり岡本さんとお話できてとても有意義でした！ また、よろしくおねがいしまーす！！

「DevelopersIO OSAKA Day One -re:union-」 #devio_osakaday1 に参加してきた

AWS 勉強会

DevelopersIO OSAKA Day One -re:union- #devio_osakaday1

classmethod.connpass.com

Day1ということは2日目があるんですかね？？？

ブース

入口でどんなエンジニアで何をしている人というマトリックスなホワイトボードに磁石を貼って中へ入場。
小腹が空いてたところ、ランチパックに惹かれてもらう。
ちいかわのランチパックが「とんこつラーメン」「焼き肉」「プリン」と変わったラインナップでこれをいただく。

奥の部屋のブースで、「GraphQL vs RestAPI」という設問があったので、GraphQL をハマコーさんに語る。
結構前から流行ってそうなのに実務で使ってる人は少ないのかな？

セッション

生成AIの活用〜RAG入門

長浜さん

  • RAG
    • Retriever + Generator
      • Retriever: 関連情報を検索
      • Nenerator: 回答を生成
  • RAGにいれるデータに古い情報が含まれてる場合
    • V1, V2 で更新されていて V1 がすでに使えないとき
      • V1, V2 両方が使えるような回答がされることがある
      • メタデータを付与してフィルタリングできる（2024年３月新機能）
        • jsonでmetadata追加して、そのファイルを除外する設定をいれる

フィルタリング機能が新しく出たのは知らなかったけど、使うメリットなんだろう？
ベクターDBから情報取り除くより手軽にフィルターできるのがメリットかと思ったけど、同じベクターDBを違うRAGでも使い回せるのが大きいメリットっぽいか？

〜小さく始めて大きく育てる〜データ分析基盤の開発から活用まで

niinooさん、Nayutaさん

  • データ品質は重要
    • Glue Data Quality でデータの品質検査実施可能
      • 簡単にデータ品質検査のルールが定義できる
      • CW で通知できる
      • 既存データを分析してレコメンドしてくれる
      • 過去データとの違いを検知（Preview）
  • Iceberg
    • Hive と違って編集可能など高機能
    • Athena で変換もできるので SFn からめて通知などもできる
  • dbt
    • ELTのT(変換)を担うサービス
    • SQLを使えればデータマート開発できる
    • 公式ではないけどAthenaで使えるプラグインもある
  • 機械学習はまずはマネージドサービスから使うのがオススメ

データ基盤の基本はもう十分抑えれるぐらいやってきたから、次は Iceberg + dbt で Athena 触ることにチャレンジするのがいいかな。

Zendeskでコールセンター・ヘルプデスク業務に手軽に生成AIのパワーを取り入れる方法

入井さん

  • コールセンターはAI活用が進んでいて5割を超えている
  • Zendesk の Advanced AI アドオン
    • チケット振り分けとかチャットボットとかAIがやってくれる
    • 分析してレポート作成
    • 要約や返信文のブラッシュアップ

コールセンター業務は生成AI前からチャットボットにAI使ったりしてたり、何かとAIと相性いいサービス。

疲弊しないAWSセキュリティ統制の考え方

川原さん

  • 良い言語化とは
    • 行動とインプットのサイクル回す
    • 良いインプット：AWS責任共有モデル、NIST CSF
  • NIST CSF
    • NIST: 米国国立標準研究所
    • CSF: CyberSecurity Framework
  • NIST CSF の Core
    • 統治(GV: Govern)：組織として戦略やポリシー立てて周知運用
    • 識別(ID: Identify)
    • 防御(PR: Protect)
    • 検知(DE: Detect)
    • 対応(RS: Respond)
    • 復旧(RC: Recover)：もとに戻す、ポストモーテムも含む
    • AWSは NIST CSF に準拠している
  • セキュリティ通知が多すぎ
    • セキュリティ通知はDetectの実装
    • セキュリティチームは数人でスケールできない
      • セキュリティ対策できる人を増やす
    • 予防対策（識別と防御）をしっかり実施する
    • Security Hub は通知しだすと凶器になりえる
      • Security Hub High < GuardDuty Medium
      • Security Hub Highでも EC2 に Public IP 付与とか緊急じゃないのもある
      • GuardDuty Medium は危険なケースも多い
  • AWSマルチアカウント管理
    • 識別、防御に役に立つ
    • 完全に権限分離ができるし課金も別
    • 強い境界線がメリットにもなるがデメリットにもなる
      • 個別アカウントの把握が大変だったり、権限管理が大変だったり
      • 技術で殴ることはできる
        • 統制用AWSアカウント使うなど

セキュリティと聞くだけで披露しちゃいます...

生成AIの最新トレンドとビジネスに活かす方法

横田社長

  • 生成AIはクラウド/IoT/ビッグデータと違い一般人も使うもの
  • 生成AIができること
    • 生成、対話、理解、連携：今まで人間に頼ってた部分をある程度任せれるかも
  • 生成AIを全社導入しても？
    • 導入するだけでは何か物足りない、使われない
  • セミナー開催すると
    • 1000社参加、200社申し込み、顧客支援20社、事例は5社
  • 今後生産年齢人口は減っていく
    • 一人あたりの生産性を大幅にあげないと成り立たない
    • サービス業は自動化無人化進む
      • ネコロボット配膳、無人レジ、予約自動化
      • 次はオフィスワーカーにもAIの波が来る？
  • AWSからのメッセージは？
    • 多様なデータ、多様な生成AI(Bedrock)、生産性向上支援(Humans)
      • 差別化するためにも自社の大量なデータが大事
        • データを持っている会社が一番強い
      • AIは良いものを使えば良い、Bedrock で実現
      • 答えが正しいかどうかは今はまだ人が選択する必要がある状況
    • 最強のAIがあっても高かったりするから適材適所
      • 小回り効く安いAIも使い分ける
  • KARAKURI LM
    • OSS の Llama2 から AWS Trainium 使って学習させて700万円で専用の LLM 作った
  • 専用のハードウェアで爆速
    • 待つ必要がないので電話対応などに使える
  • 独自のLLM作るには？
    • OSSのLLMに自社データを食わせて人がアライメントして調整する
  • マルチモーダルなAI
    • 写真から状況を言語化したりその逆をしたり
  • 軽量LLMがEdgeへ移動していく

最初のアイスブレイク的な話題にて「勢いで引っ越しました」「勢いでベルディーのサポーターになりました」「勢いで国立博物館や動物保護施設に寄付しました」などなど、勢いのある会社の代表の凄さを見せつけられました。
年末に思い立って引っ越し計画してから、この４月で引越完了してる勢いがすごいし、引っ越し担当をいつもしてくれてた外部の人が社員になって対応してるのもすごすぎ。
東京のオフィスと同じ床材つかったりしており、雰囲気は一緒ですね。

プレゼン内容もこの1年で使うのを当たり前になった感じのするLLMをしっかり語れるのがすごい。
AWS12冠だし、トレンドにも強いし々エンジニア以上に学んでる感があるんですが、この大きさになった企業の社長にいつそんな時間があるんだろうか？
生成AIはちゃんと追っかけて使うところまで進めたいし、色々ヒントを貰えるいいセッションでした。

「Geeks Who Drink in Osaka！〜Tech好きが集まる福岡発イベントの大阪開催〜」に参加してきた #GWD_Nulab

勉強会

Geeks Who Drink in Osaka！〜Tech好きが集まる福岡発イベントの大阪開催〜

nulab.connpass.com

大阪初のヌーラボのイベントです！

いきなりお食事が提供されるイベントは久しぶりでした！
話を聞くと、関東では寿司おじさん問題もあるのでいきなり食事提供は控えることもあるようですが、それ以外のところではその被害は及んでないとのことでした。

セッション

ZigでWasmのSpecの壁を乗り越えた話

株式会社ヌーラボ サービス開発部 Backlog課 松本 裕二さん

  • Wasmの仕様を理解ついでにZig使いたい
    • SpecはPDFで159ページ
      • C++は1853ページ...
    • 準備されてる Test suite は26,000件
  • ZigでWasmのインタプリタを作ってみた
    • 仕様がありテストを通す目標があるのでやりやすい

エンジニアならわかるらしいです。
なるほど、全然わからん。

Feature Teamの枠を超えた話〜OpenAI連携プロジェクトのはじまり〜

株式会社ヌーラボ サービス開発部 Backlog課 中村 壮一

  • OpenAIと連携した「AI要約」機能をリリース
    • 当初はBacklogのロードマップにAI連携はなかった
    • 競合企業が次々AI関連機能をリリース
  • ハッカソンを通してプロトタイピング
    • Gitチームで他のプロジェクトを止めてOpenAI連携に取り組み
    • Feature Teamの枠を超えてできた成功体験

危機意識からのスピード感もすごいし、他のプロジェクトを止めてまで全然関係なかったチームが取り組めるって素晴らしい。

LT1 承認を組み込みたい

りなたむさん

  • Backlogに承認を組み込みたい
    • Power Apps でライブ実装...回線遅くて繋がらず
    • Power Automate で実装...回線切れ

「業務文化はローコード・ノーコードで！」というデモでした。
その後すぐに作成完了してました。

LT2 採用でプロダクトの壁のりこえ

杉田さん

speakerdeck.com

  • 入社2ヶ月でエンジニア10人採用を任された
    • 採用担当のプロダクトがわからないと話せない
      • プロダクトの説明をしてもらい、面接での上司の話を聞いて覚える
    • エンジニアとデザイナーの名簿を作ってロールと担当プロダクトを書く
    • エンジニア採用ページを作りヒアリング

6名採用できたとのこと。
この時代に5ヶ月弱でこれだけ集めるってすごい。

LT3 SAML対応を乗り越える

新井さん

https://www.canva.com/design/DAF_3kmQ3Rk/E_46djbYksqVhiK98m76eA/edit

  • 名刺管理のメイシーを作ってた
    • 利便性の検索機能が求められてたところからセキュリティメインの時代に

「SAMLは簡単なのでやってみよう」という話でした。
確かに一度やってしまうと簡単にできるんですよね。
EntaraIDとか管理側のSaaS触る権限持ってればすぐできる。

LT4 緩急をつけたプロダクト開発でレガシー業界の壁を乗り越える

白石さん

  • 製造業向けのSaaSプロダクト開発
    • 製造業はレガシー業界で70%は赤字
      • そのため顧客との信頼関係が大事
  • 4つのFit
    • Custmer Problem Fit
      • あなたの課題を理解していることが重要
    • Problem Solution Fit
      • この仕組みで解決します
    • Solution Product Fit
    • Product Market Fit
  • プロトタイピングで可視化を重要視している

プロトタイピング＋営業さんの力で4つのFitを意識して「これで核心をつくサービスは作れる」と。

LT5 ＩＴ/ＳａａＳ業界ートップセールスであり続けるために乗り越えてきたことー

米田さん

  • 仕事を楽しめてる理由
    • 目標を定めて達成するプロセスや創意工夫で数字が変わる
    • できるようになる工夫が楽しい
  • 上を目指す楽しさ
  • で？だから？どうする？
    • 自分に問う
  • 絶対にできる信念

営業さんらしいパワフルさが伝わるプレゼンでした。

IPOを乗り越える

株式会社ヌーラボ 情報統括部 セキュリティエンジニア 松山 保さん

  • 伝えたいこと
    • 国語力、記録、課題の突破力、組織の総合力
  • 2022/6/28に上場
    • 上場の申請には2年分の会計に関する監査証明が必要
    • 2017年からアドバイス受けながら体制構築
  • 会計監査とは？
    • 監査法人の監査を受けること
      • 社内のワークフローがドキュメント通りに動いているか？
      • 証跡が大事で改ざんできないこと
  • 上場審査基準に照らして証券会社が審査する
  • 用語の定義から必要

上場するためには現場にも色々負担が増えるのね。
ストックオプション無いとモチベ上がらずつらそう。
「ご理解のとおりです」と審査員に答えるとうまく進むと。

エンジニアから事業開発を経て代表になるまで ～ロールを越える～

株式会社ハカルス 代表取締役CEO 染田 貴志さん

  • HACARUSはものづくりの現場DXを実現するAI製品
  • 過去の経験
    • サーバーインフラ経験
    • PM経験
    • 営業経験、創業経験
      • 売上がなくて大変で受注する喜びはエンジニアでは味わえなかった
      • 利益があって給料になるという腹落ち
      • 人に会う大切さ
    • サポート経験
      • リアルに使う人の本音
      • プロダクトを通じてユーザに伝える難しさ
      • UI/UX大切さ
      • 解決できればユーザーは満足
      • 人に会う大切さ
    • 広報経験
      • 知ってもらう手段を知った
      • 行動の結果が出るまでの時間軸の違いを知った
      • 人に会う大切さ
  • ロールを超えて見えたこと
    • 自分の得意不得意
    • 課題に対する手段が増える
    • 立場が違う人の視点がわかる
  • ロールを超えるために心がけること
    • 軸をしっかりもつ
    • まずはやってみる
    • 大ジャンプしない

楽しみにしてた染田さんのお話！
いつの間にかにCTOから代表取締役になってました。
「しゃべるの得意じゃなかった」と。
わかる、自分も全然人前で喋るとかできなかったのにいつの間にか当たり前にできるようになった。
染田さんでもそうだったのは意外でした。

所感

ヌーラボさま、関西でも楽しいイベントを開催いただきありがとうございました！
BacklogにCacooとヌーラボ製品ファンなので引き続き応援してます！

「インシデントマネジメント 事態収拾のための取り組みに迫る Lunch LT」#インシデントマネジメント_findy 受講メモ

勉強会

インシデントマネジメント 事態収拾のための取り組みに迫る Lunch LT

findy.connpass.com

セッション

LT①「BASEにおけるインシデント対応フローと工夫」

BASE株式会社 大津さん

  • 障害検知したらインシデントチャンネル作成
    • 自動で関係者をbotがインバイト
  • プレモーテル
  • 復旧対応
    • インシデントの重大度に対応したToDoリストに応じて対応
  • 再発防止・クロージング
    • ポストモーテムの内容が問題なければCTOがクローズ
  • 参考ドキュメント

フロー整備をトップダウン・ボトムアップ両方で作ったと。現場の意見が入っているのは大事。
自動化多めなのはいいですね。インシデント対応時は余裕が無いし。

LT②「Luupの開発組織におけるインシデントマネジメントのこれから」

株式会社Luup Wataru Tsudaさん

speakerdeck.com

  • インシデントマネジメントツール
    • Waroom を導入、60,000円/月

Waroomは決して安くは無いけど、ツール利用して進めると標準的なフローで動くことができるので、値段なりの価値はありそう。

LT③「インシデントマネジメントとエンジニアリングのかけ算」

GMOペパボ株式会社 伊藤 洋也さん

speakerdeck.com

  • 機密性・完全性・可用性
    • 3つのうちどれかが発生するとインシデント
  • 準備・対応・事後対応
    • 準備：インシデント対応マニュアル
    • 対応：エンジニアリングで自動化
      • Slack botでインシデント対応の進行を自動化
    • 事後対応：トラッキングとフォローアップ
      • botでポストモーテムを半自動化
      • ドキュメントはOpenAI+RAG+ベクトルデータベースで検索

インシデント事にSlackチャンネルセットアップするって結構一般的なのかな？PagerDuty 使うとそうなるらしいと。
RAG作って検索できるようにできるのイマドキだわ。

LT④「手を動かさないインシデント対応 - 自動化で迅速・正確な運用を目指す」

PagerDuty Kazuto Kusamaさん

  • 「PagerDuty いいサービスですね！見たくないど」
  • インシデント中は二次災害など失敗することも多い
    • Runbook をまずは作る
    • 自動化で作ってしまう
    • CloudWatch などから自動で PagerDuty 経由で Rundeck に投げる

登壇に合わせて事前に仕込んだポストが投稿されていて、内容も素晴らしいけどプレゼンレベルがとても高い！だから進行時間を気にしたりしていたのか。

「JAWS-UG東京 ランチタイムLT会 #8」 #jawsug_tokyo 受講メモ

AWS 勉強会

JAWS-UG東京 ランチタイムLT会 #8

jawsug.connpass.com

セッション

LT① AWS認定を全部取って、ふた月が過ぎました

speakerdeck.com

さかぐちさん（株式会社エーピーコミュニケーションズ）

  • 全冠とったけど...強いエンジニアになれたとは思えない
  • 資格は目的じゃなくて手段
    • 高みへ至るためのルートにはなる
  • 周りからは良く見えるのでプレッシューもあるし目標もできる
    • 全冠だけのエンジニアにはならないようにする

受けるだけですごいし、ちゃんと全部取るのはさらにすごい。

LT② AWS Well-Architected Toolで信頼性をレビューした結果

岩本 隆史さん（ENECHANGE株式会社）

speakerdeck.com

  • AWS Well-Architected Tool 信頼性チェック
    • 13個の大きな設問に答えていく
    • 短い時間でレビュー完了
      • 1ヶ月半の期間で対応し、レビュー時間は3時間半
    • リスクが明確になる
      • レビュー前の漠然とした不安が消える
    • ベストプラクティスが高水準
      • レイヤーの自動回復とか
    • できるところは対応
      • EBS暗号化など

短期間でリスクが明確になるのはいいですね。
チェックだけとはいえ、この取り組みするのに重い腰を上げる必要がありそう。

LT③ 小さな事から始めるAWSコスト最適化

森 祐太朗さん（株式会社キュービック）

speakerdeck.com

  • コスト削減を何から始めればいいか初学者には難しい
    • EC2, ECS, RDS のコスト削減から
  • EC2 自動起動停止
    • Instance SchedulerがあったがSystem Managerでもっと簡単に
    • System Managerの「高速セットアップ」から "Resource Scheduler" を利用
  • ECS/RDS 自動起動停止
    • EventBridge Schedulerで対応

昔はLambda使ったりAutomationとDocuments使ったりしてたけど、より簡単にできるようになってるんだ。

LT④ リソースをIaCで管理しよう

佐藤 亨さん

  • CloudFormation
    • AWSリソースをテンプレート化
    • 各種設定を明示できるのがいい
  • IaCジェネレーター
    • 既存リソースをCFnに取り込むことができるようになった
    • AWSリソースをスキャンして選択したCFnテンプレートを生成
      • 論理IDがわかりにくい
      • タグなどの再現は便利

結局できあがる CFn を読み解く力が無いと厳しそうだから、CFnの勉強は必要そう。 きっかけいにはいいよね。

LT⑤ CDKで案件の途中で子スタック分割する羽目になり苦労した話

中條 大輔さん（東京海上日動システムズ）

  • APIG が再作成されるとWAFへの再登録が必要になる
    • 親スタックで APIG 作っててそれを残さざる得なくなり、子スタックでLambdaを作成
    • 最初から子スタックで APIG 作成するべきだった

スタック分割すると発生する問題。
最初からわかってればできるけど作っていくうちに変わるので難しい問題ですね。