間丈 こんにちは。勉強会運営の間丈です。
先日、第6回社内LT大会（テーマ：AWS）を開催しました。
LTとは「ライトニングトーク」のことで、一般的には5分程度の短い時間で行うプレゼンテーションです。
クリエーション・ビューではAWSの資格取得を奨励していますが、「現在の業務ではAWSを利用していないため、資格が業務にどう結びつくかイメージしづらい」という声が寄せられました。
そこで、資格学習で学んだサービスを業務で利用するイメージを掴んでもらうため、「実際の業務でAWSのサービスをどのように活用しているか」を共有するAWSの社内勉強会を開催することになりました。
今回は1人10分のLTの形式で、5名の登壇者の方に業務でのAWS活用事例をお話しいただきました。
「どのような要件・機能を実現するために、どのサービスが利用できるのか」、「他のどのようなAWSサービスと連携しているのか」など、新しい発見や学びの多い会となりました。ここからは、各登壇者の発表を簡単にご紹介します。
発表内容
①AWS CDK
1人目の登壇者の方は、AWS CDKの概要と、利用して感じたメリット・デメリットをお話しくださいました。
AWS CDKは、コードでクラウドインフラストラクチャを定義・管理するIaC（Infrastructure as Code）のフレームワークです。
内部的にはAWS CloudFormationテンプレートを生成しますが、CDKは「書き方を開発者向けに引き上げる」ツールとのことです。
開発者が慣れた言語でコードを作成できたり、Constructという単位で再利用性を高めたりできるのはうれしいですね。
一方で、フレームワークにラップされることで見えにくくなる部分もあるため、権限やポリシーの観点を中心に生成物のチェックは欠かせないとのこと。
導入時のポイントとして、CDKは「AWSを隠す道具」ではなく「AWS設計をコードとして標準化する道具」と捉えると失敗しにくい、とお話しいただきました。
「キャプチャ古くない？」と思いながら手順書を見てポチポチした経験を思うと、IaCの頼もしさはひとしおです。
各サービスやリソースに与える権限には十分気をつけながら、IaCの管理のしやすさを享受したいと思いました。
②Amazon Athena
2人目の方が話されたのは、Amazon S3をデータレイクとして、BIツールからの参照時にAmazon Athenaクエリを実行するデータパイプラインの構築事例について。
Amazon S3はオブジェクトストレージのサービス、Amazon AthenaはAmazon S3に保存されているデータに対して、サーバーの管理・構築不要でクエリを実行できるサーバーレスなデータ分析サービスです。
ご紹介いただいた例では、扱うデータ量が大きいため、データパイプラインではキャンセル済みのデータを削除したり、対象期間を絞ったりと、処理が重くなりすぎないよう考慮されているそうです。
同プロジェクトでは仕組みの異なるデータパイプラインもあるそうで、こちらはAmazon Athenaでクエリを実行するのではなく、事前に参照データを作成してSnowflakeというデータプラットフォームに登録しておくというもの。
前者は表示は遅いものの最新データが参照でき、後者は更新頻度の低いデータを早く表示できる利点があるため、閲覧したい情報の特性に応じて使い分けているとのこと。
情報の鮮度とレスポンスの早さはトレードオフとなることが多いと思うので、データの用途を理解して適切なバランスを見つけるのが重要なのだと改めて思いました。
③Amazon Bedrock
3人目の方が紹介されたのは、既存システムにAmazon Bedrockを活用した機能を追加する事例でした。
Amazon Bedrockは複数のAIモデル（基盤モデル）をAPI経由で利用できる、フルマネージドな生成AIサービスです。
生成AIに自社のデータを組み合わせるRAG（検索拡張生成）の構築や、AIが複雑な判断を自律的に行う自律型エージェントなどの機能を備えています。
こちらの事例では、日付のフォーマット統一やPDFの要約、HTMLのテーブルの解析機能を実現するために導入したそうです。
システム全体はレガシー気味だそうですが、問題なくAmazon Bedrockを活用した機能が追加できたという実績に勇気をもらえますね。
導入時には、AIのみですべてを解決しようとせず、プログラムとの併用も検討するのがよいとお話しいただきました。
Amazon Bedrockの器用さ・導入しやすさを感じられると同時に、正確な結果を得るためには、出力のブレの程度や傾向を丁寧に検証する必要がありそうだという学びを得た発表でした。
④Amazon CloudWatch
4人目の方には、CloudWatch Logsのサブスクリプションフィルターでエラーログを検出し、通知する仕組みを構築した事例をご紹介いただきました。
Amazon CloudWatchは、AWSリソースやアプリケーションを監視・管理するためのサービスで、メトリクスやログの管理・分析、ダッシュボードの作成などが行えます。
このサービスのログに関連する機能がCloudWatch Logsです。
こちらのプロジェクトでは、CloudWatch Logsのサブスクリプションフィルターでエラーログを検知し、AWS Lambdaで整形してチャットツールへ通知する仕組みを構築したそうです。
実装のなかで、ログから必要な事象を検知できるよう、ログ設計の重要性を実感したとのことです。
また、資格学習で学んだ知識が、権限設定や費用の算出、利用サービス・構成の検討に役に立ったとお話しいただきました。
個人的に、独学のときにはログや通知のような運用観点の部分を後回しにしてしまいがちなのですが、業務では欠かせない視点ですよね。
運用時の視点を持って設計・開発に臨む重要性を再認識しました。
⑤AWS Step Functions
5人目の方は、運用・保守寄りの作業に対するAWS Step Functionsの活用事例を紹介してくださいました。
AWS Step Functionsは複数のAWSサービスやシステムをワークフローとして連携できるサーバーレスのオーケストレーションサービスです。
引用: https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/welcome.html
1つめの例は、不定期で停止してしまうECSのサービスを再起動するためのフロー。
2つめの例は、日次の勤怠実績CSV出力。Lambdaを並列で呼び出し、それぞれ異なるデータを参照する箇所があるそうです。
いずれの例もエラーハンドリングと通知には改善の余地があると補足されていましたが、発生頻度やフローの重要性・緊急性を勘案してコンパクトに構築しているのだろうと感じました。
1つめの例から、AWS Step Functionsがシンプルなワークフローでも活躍することが伺えます。
「オーケストレーション」というと壮大な感じがしますが、こんなに単純なテンプレートも。
シンプルな構成から始められる点も、AWS Step Functionsの魅力の一つだと感じました。
おわりに
今回のLT大会では、業務でAWSサービスを活用している方の知見を共有いただき、多くの学びを得ることができました。
AWSの学習を進める中で、サービスの機能や特徴を暗記しても、「実際にどのような場面で活用できるのか」を具体的にイメージすることは意外と難しいものです。
その点、今回紹介された業務での活用事例や、実際に利用して感じたメリット・デメリット、導入時の注意点などは、教材だけでは得難い貴重な情報でした。
試行錯誤しながら得た経験を共有してもらうことで、新たな視点や気づきを得ることができたのではないかと思います。
LT大会は、「せっかく勉強したから共有したい」「便利なサービスだからぜひ知ってほしい」といった思いを形にできる場です。
これからも、若手社員を含め多くの社員が気軽に挑戦できるLT大会を目指していきたいと考えています。
なお、登壇者目線の感想をまとめた「社内 LT 大会に参加してよかったこと」という記事も公開していますので、興味のある方はご覧ください。
次回のLT大会ではどのようなお話が聞けるのか、今から楽しみです。
