[セッションレポート]クラスメソッド x フォージビジョン x Fusic【AWS勉強会】 #classmethod_forgevision_fusic

クラスメソッド x フォージビジョン x Fusic 3社合同のAWSをテーマにした勉強会にオフライン参加してきました

#セッションレポート

#AWS

べこみん

2023.05.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

本記事は下記イベントにオフライン参加した際のセッションレポートです。

「AWS」という広いテーマで色々な面白いセッションを聴くことが出来ました。

アーカイブ動画はこちら（※YouTubeリンクです）

ChatGPTを使った文書の学習システムをサーバーレスで作ってみる

登壇者
- クラスメソッド Natsume Yuta 氏

レポート

自己紹介
- クラメソCX事業本部サーバーサイドチーム
- 自称サーバーレスエンジニア
- 好きなAWSサービスはLambda, DynamoDB, SQS, Glue
- 最近FF14と崩壊スタートレイルが忙しい
LlmaIndexについて
- LLMIは対象の公開情報で学習されている
- OpenAIのLLMIを利用することもできる
作りたいもの
- DevelopersIOの記事（約40,500記事）を収集する仕組み
だが、完成していない
その理由（言い訳）
- 文字列を解釈するライブラリでエラー
- めちゃくちゃ時間がかかった
- 自宅のGaming PCでメモリ26GB使えるように
  - 頑張って学習したら2日で学習完了
- 完了したものは6.5GB
- ここからどう学習させるか
- Indexファイルを維持する
  - 社内に展開
- Indexファイルを諦める
GlueのPython Shell Job
- AWSのサーバーレスコンピュートリソースの1つ
- Python3.6か3.9のどっちか
- 使えるライブラリ
- ある程度最初から入っている
- Python3.9
  - 分析ライブラリセット
- ライブラリを追加したい場合、 --additional-python-modulesというJobパラメータが必要
- 独自のコードを追加したい
- ,whlダイルとしてパッケージング→S3に保存、 --extra-py-filesにS3のURLを記載
- しかし、公式ドキュメントには違う方法がある
- setup.pyを書くのはちょっと面倒
- ということでpoetryを使った
- poetryって何？
- pipenvとほぼ同等の機能
- pipenvと異なり、ビルドもできる
- poetryでPythonパッケージを作る
- llma-indexをインストール
- distディレクトリにwhlファイルとかが作られる
- 色々辛いのでFargateを使う
- Fargateは広義のサーバーレス
- まだ検討段階だが、実行状況を管理したいからECS Taskが良さそう
- IndexをJSONとして保存することを諦める
- llma-indexのStorageの話
- llama=indexのストレージでは3つのstoreを設定する
- デフォルトではそれぞれSimpleDocumentStore, SimpleIndexStore, SimpleVectorStore
  - 最初の2つは内部的にはKV
  - Vectorの中身はただのdict
- KVのものはmongoDBで既に実装されていた。じゃあDynamoDBもいけるんじゃない？ってことでStorageにするPRを出した
  - 無事にmerge！
Kendraの役目は文書のフィルタリング
今後やること
- KendraやOpenSearchを使った文書検索システムの検証

感想

約40,500記事もある弊社ブログの内容を収集するためのツール開発についてのセッションでした。 poetryは最近私も使い始めましたが、確かに他のpythonパッケージマネージャーに比べ色々なことが出来るという印象を受けています。

インフラエンジニアによる AWS 設計のはじめかた

登壇者
- フォージビジョン松尾氏

レポート

自己紹介
- 最近福岡に引っ越してきた
- 自称魚介系エンジニア
- 神経締めが出来る（エンジニア界唯一？）
AWSを触り始めた頃は7つだったベストプラクティス
- その後、11個のベストプラクティスが登場
- 7つのベストプラクティスと重複してるものがある
ただし、これらはあまりAWSに関係が無く、エンジニア次第なところがあった
現在はAWS Well-Architected Framework
- よりAWSに寄り添った内容
- ベストプラクティスと各サービスの関係が分かりやすく！
- 最近大幅アップデート
さらに、特定分野や業界に向けたレンズやガイダンスも
組織優先順位についてのベストプラクティス
ただ、全部網羅するにはボリュームが。。。
- そこで、AWS Well-Architected Toolを使おう！
- 独自のカスタムレンズを適用することも可能
Toolとは
- 対話形式でレビュー項目を1つずつチェック可能
- レビュー後は管理画面で結果を確認可能
ただし、スピーディーに要件定義を行う必要がある場合にはWell-Architected Frameworkは向いていない
そんな時は以下のコンテンツがおすすめ！
- AWS サービス別資料（Black Belt）
- AWS 初学者向けハンズオン
- AWS クイックスタート
- AWS リファレンスアーキテクチャ
- 参考: AWS リファレンスアーキテクチャ図
- AWS スキルビルダー
- AWS ブログ
- Ask an Expert
- AWS Loft Tokyo（東京・目黒）で行われているオフラインの相談会
あとはAWS公式から情報を収集するのもOK
- AWS認定パートナーや個人が執筆している技術ブログ
- あとは飛び道具としてChatGPTもありかも？
課題解決ではなく情報収集だけが目的の場合、AWSのイベント参加もおすすめ
- AWS Summit Tokyo
- AWSOME DAY
- 今年は6/8
- AWS DEV DAY
- 今年は6/22, 6/23
- 開発者向けのテクニカルカンファレンス
- AWS re:Invent
- 世界最大のAWSイベント
- 今年は11/27〜12/1にラスベガスで開催予定
あとはコミュニティに参加して情報収集するのもあり
- JAWS-UG
- AWS Users Group - Japanの頭文字をつなげた言葉
- 様々な分野の支部があるので、自分が興味のあるものに参加してみよう
- ただ、コミュニティ系のイベントはインプットだけでなくアウトプットも！！
マネージドサービスをすると運用の負担が減る
- まずはサーバーレス系のサービスから検討する
IPAの非機能要求グレード
- 可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー
- ↑が網羅的に書いてある。凄くよく出来た資料。
- クラウドサービスでも十二分に活用出来る！！
- ただし、Well-Architected Frameworkと同じくかなりの時間が必要。。。
まとめ
- AWSの設計をどう進めていくかを考えるために様々な情報を活用しよう！
- ただし、ギブアンドテイクの精神で！自分もギブしていこう！
- フォージビジョンさんは社員を絶賛募集中！

感想

AWS設計を行うにはどのような情報を得れば良いのか？という話から、どうやってAWSの情報を取得するか？という話にも繋がっていました。実際に自分がよく参考にしているドキュメントも多く、賛同する箇所が多かったです。また、AWSドキュメントだけではなくIPAの非機能要求グレードも設計においては非常に参考になるドキュメントですね。

恋の始まり自動化してみた

登壇者
- Fusic 苑田(そのだ) 氏

レポート

自己紹介
- 新卒3年目
- 自称緑タイツマン
- 2023 Japan AWS Jr. Champions！
背景
- みなさん、恋してますか？
- ドキドキすると、勇気が出ず、告白が出来ない
- そして失敗する。誰しも経験があるのでは？
- モジモジしたくない。。。そうだ！自動化しよう！
- 令和なのでChatGPTに「なんでドキドキするんですか？」と聞いてみた
  - ChatGPT「恋愛感情を持っているのでは？心拍数を上げるのです。それが恋です。」
- 一定の心拍数を超えたら告白する「恋のキューピットBot」を作ってみた
具体的に何をしたのか
- 構成
  - ラズパイ
  - Iot Core
  - IoT Events
  - S3
  - Lambda
  - OpenSearch Service
    - 心拍数を見るため
- IoT Coreについて
  - ルールで決められた通りにルーティングする役割
  - ルールとは？
    - デバイスデータを変換し、AWSサービスにデータをルーティングする仕組み
- IoT Eventsについて
  - オペレーションの変化をモニタリングし、その変化をトリガーにアクションを行う
  - 今回は「20秒間心拍数が100を越え続けていたらSlackに通知を飛ばす」というイベントトリガーを設定
  - なんでこんなルールにしたのか？
    - 1秒間だけだと、閾値を超えるたびに無限に告白してしまう
恋の始まり自動化してみた（デモ）
- 会場に好きな女の子はいないので運用でカバー
  - 会場にいた苑田さんの上司の方がスクワットをして心拍数を上げることに。。
- 100はキツいので閾値を80に下げてみた
- （しばらく成人男性が筋トレし続ける様子を見てました）
- 今回は謎のエラーが発生してデモ失敗
  - 今度どこかの機会でリベンジあり
まとめ
- IoT Coreを使うことでルーティングできた
- IoT Eventsを使うことで複雑な処理ができた
- Botに頼らず自分で愛を伝えよう！！
質問
- IoT Eventsで一度告白したら二度と告白しないような仕組みを作れるか？
  - 頑張ればおそらく出来るはず

感想

タイトルからマッチングアプリを自動運用する話かな？と思ったら心拍数を使ったメチャクチャ面白い話でした。デバイスとしてはラズパイに心拍数を計測するためのモジュールが組み合わさっている感じでした。（下図参照）

AWSに関するOSS活動で得た貢献までの壁を越えるコツ

登壇者
- クラスメソッド Imaizumi Taiki (bun913) 氏

レポート

"OSS貢献に壁なんて無かった"
自己紹介
- Twitterとかでは bun
- 現インフラエンジニア、元はソフトウェアエンジニア
- ダイの大冒険ガチ勢
OSSとは？
- まさかりが飛んできそうなので下手なことは言えないが、今回は以下の定義
  - コードが公開されているソフトウェア
  - 誰でも触れる
OSS貢献は何が嬉しいのか？
- GitHubのプロフィールが強く見える
- 仕事ほどプレッシャーを感じないが世界中で使われるようなプロダクトに携われる
- すごい人からレビューとかコメントをもらえる
- 自己肯定感が上がる
OSSの流れは基本的に一般的な開発と同じ
実際に私がしていた勘違い
- 1. OSSのプログラマーにはツヨツヨな人しかいない
- 最初は美術品に手を加えるような恐ろしさがあった
- でも実際はそんなことない
- 某IaCのコードでもぱっと見ただけでひどい箇所がたくさんあった
  - if文のネストが深い
  - 冗長な書き方
- 1. 深く理解していないと書けない？
- そんなことない！
- まずは自分が仕事で関わっている領域で探してもいい
- 自分の好きな言語で書かれているものや、初心者向けのIssueを探してもいい
  - Good First Issue というサービスでも探せる
- 自分が好きなツールで探す
  - 自分の好きなツールだとモチベーションが上がる
  - Raycast（リンク）というツールが好き
- 既存で便利ツールが無いなら作っちゃうパターンもあり
- 1. 英語が出来ないとやり取り大変だよね？
- マジでそんなことない。今では無料で使える翻訳ツールがすごい。
- 最近はChatGPTを使うのもあり
- ただ、変な返信文章が生成されて微妙な空気になったことも。。。
  - ちゃんとエンジニアらしく裏どりしようね
これらを乗り越えてPRがマージされると。。。
- すごい人から褒めてもらえる！
- しかもGitHubのプロフィールに格好いいマークが付く！！！
たくさんコントリビュートすると良いことが
- AWS CDKの場合、最初はbeginner→3つするとrepeat→6つするとほげ
AWS CDKへの貢献のTIPS
- AWS CDKはIaCツール
- 数行の短い記述でAWSのベストプラクティスな構築ができる
- コントリビュートへの流れは CONTRIBUTING.md にまとまっている
- jsiiという仕組みでTypeScriptから他の言語へと変換
- コントリビュートする際はTypeScriptのリポジトリだけでOK
- リファクタリングも結構歓迎
  - issueを立ててさっさとPR作ってしまっても案外OK

感想

OSSへのPR、自分もなかなか勇気が出なくてやれていなかったんですが、去年初めてPRを出してみました。本当に簡単なissueも多いのでこれからも少しずつ貢献していきたいですね。

コードが書けなくても Step Functions 使ったらええやん

登壇者
- フォージビジョン八木氏

レポート

自己紹介
- 最近福岡に引っ越してきた
  - タイトルを「使ったらよかろうもん」にすれば良かった
- 飲食業→営業職→AWSエンジニア
- 好きなAWSサービスはAmazon CloudFormation
はじめに
- AWS Step Functions とは
  - AWSの各サービスで実行される処理をまとめて1つの連続した処理にできるサービス
  - JSON形式で記述可能
- エンジニア歴は浅かったが、Step Functionsを使った案件にアサイン
  - 結果、Lambdaを使わなくてもStep Functionsだけでやりたいことを自動化出来た
やったら ~~ええやん~~ よかろうもんな理由
- 理由その１「Workflow Studioが優秀すぎる！」
  - Step FunctionsのステートマシンをGUIで構築出来るやつ
  - しかもそのあとJSONコードも生成してくれる
- 理由その２「AWSのAPIに詳しくなれる」
  - 200以上のAWSサービスをサポート
  - APIがどんな出力をするのかにも詳しくなれる
  - APIを触っていて気付いたこと
    - SDK（boto3）のAPI仕様とAWS API仕様が違った。みんなも気を付けよう。
- 理由３「ちょっとしたデータ加工は組み込み関数でLambda入らず」
  - 組み込み関数でちょっとしたパラメータの加工が可能
  - カスタムパラメータグループを作った
    - 不要な改行コードを削ってくれるもの
まとめ
- とはいえ、独自の処理にはLambdaが必要
- ただ、AWSサービスだけを使った連続処理であればStep Functionsだけでかなりのことが可能！
  - 少なくとも、AWS CLIを使ったスクリプトは書かなくていいかも
- 最後に、ChatGPTにStep Functionsの作り方（JSON）聞いてみた
  - ただ、エラーだらけのコードが出てきた
  - インプットが甘かったのもあると思うが、まだChatGPTに仕事を奪われることは無さそう

感想

私も最近よく使っているStep Functionsのお話でした。実際にはLambdaを挟んで使うことも多いと思うStep Functionsですが、定型的で簡単な処理であれば確かに用意されている組み込み関数で弄れるので良いですよね。

AWS Well-Architected セキュリティの柱を利用したセキュリティリスクアセスメント方法について考えてみる

登壇者
- Fusic 藤澤氏

レポート

自己紹介
- ソフトウェアエンジニア
- TryHackMeを最近始めた
- 2023 Japan AWS Jr. Champions！
NIST CSFとAWS Well-Architected Framework セキュリティの柱について
- セキュリティの柱とは？
  - あらゆるセキュリティ領域・側面からデータとシステムの保護に焦点を当てたベストプラクティスが定義されている
- NIST CSFとは？
  - NISTが2014年に発行したサイバーセキュリティフレームワーク
  - 汎用的かつ体系的なセキュリティ対策を行うことが出来る
- 両者を見比べた時、結構セキュリティの柱にNIST CSFの観点が入っているように見えた
セキュリティの柱のまとめ
- AWSベストプラクティスの観点が含まれている
- クラウドセキュリティにおける設計原則が定義されている
- NIST CSFの観点が含まれている
SecurityHubとの比較
- 3つのセキュリティ標準がある
- スコア化機能もある
- セキュリティの柱と比較してみた
  - Security HUbは早くて楽にアセスメント可能
    - Configと連携して利用可能
    - デメリットはAWS外を見てくれない
- Security Hubのまとめ
  - よりAWSに寄ったアセスメントが可能
AWS Well-Architected Framework セキュリティの柱のアセスメントフローとスコア化について
- Security Hubのようにやりたい！
- 領域を中項目 > 小項目に分ける
- 小項目を満たすための実装ガイダンスを読み込み、小項目ごとにTODOチェックリストを作成
- チェックリストを全て満たしているものは⚪︎、一部満たしているものは△、そもそもAWSの設計的にNGなものは×
- AWSリスクレベルの重みづけも行った
- アセスメント結果を縦軸、AWSリスクレベルを横軸にし、スコア化
  - AWSリスクスコア = AWSリスクレベル * アセスメントスコア（⚪︎=3,△=2,×=1）
結果的に得られたメリット
- クラウド外の環境も含めた網羅的なアセスメントが可能
- 押して気軽に始められる（工数は気軽ではない）
スコア化するメリット
- 対策事項に優先度がつけられる
- 進捗度を可視化
- 数字ベースでお客様に説明可能

感想

本日2つ目のWell-Architected Frameworkに関するセッションで、個人的には一番興味深かったセッションでした。確かにAWS外の部分についてもSecurity Hubのようにスコア化して可視化出来ると良いですよね。ちなみに、セッション後で登壇者の藤澤さんと「この仕組み、自動化したいですね」というお話で盛り上がりました。