ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

DevelopersIO 2023 福岡に行ってきました #devio2023

こんにちは、クラウドインテグレーション事業部の遅れてきたルーキー八木です。

私の住んでいる九州界隈でも昨今はオフラインイベントが盛んになってきております。

そんな中、日本でもトップクラスのAWSエンジニアが多数在籍するクラスメソッドさん主催のカンファレンスイベントDevelopersIO 2023が福岡でもオフラインで開催されると聞きつけ行って参りましたので、その参加報告をしたいと思います。

午後一で始まったイベントは計13セッション。登壇者の方が業務から得た知見を惜しみなく披露されており非常に学びのあるイベントでした。

すでに登壇者の方々がご自身のブログを公開されているものがあるので、詳細はそちらをご参照頂くこととして、こちらではセッションの概要と私の簡単な感想のみ述べたいと思います。

笑顔でAWS: モチベーションを保つための秘訣

  • 登壇者:平野文雄さん
  • 学習の継続がエンジニア以外のビジネスパーソンにとっても必須の時代が到来している
  • AWSを学び始めたきっかけ
    • 業務上の必要性がトップ、その他セミナーなど
  • モチベーション継続理由
    • 生活のためがトップ(身も蓋もないですね笑)
    • 次いで実際に構築してみる、自らの知識欲、自分の興味ある技術に取り組む、イベント参加、資格取得、案件、独り立ちしたいなど様々
    • ドヤりたいというのも立派なモチベーションなので十分活用すべき
  • 挫折しそうなときどうするか
    • 事例を参照したり、自分に理解しやすいように変換
    • 素直に距離を置いてまたもどってくる
    • 相談する
  • AWS学習を楽しむの秘伝のタレ教えて
    • ブログなどでアウトプットする
    • What's new AWSで最新情報をチェックする
    • 未来の自分を想像する
    • AWSすごい人と会話する
    • 得意じゃないサービスを扱うAWS案件にあえて飛び込む

感想

普段からLT登壇やブログで物凄いアウトプットをする社内外のエンジニアの方々がいらっしゃるのを拝見していますが、意外とモチベーションは自分と大きく変わらないところにあるというのが発見でした。自分も引き続き精進したいと思います。

コンタクトセンター業界の動向とAmazon Connect & 周辺のAWSサービスについて語り尽くす

  • 登壇者:洲崎 義人さん
  • Amazon Connectの利用方法はコンタクトセンターかそれ以外かの2つ。本セッションは前者を想定
  • コンタクトセンターについて
    • コンタクトセンターの業務は、カスタマーサポート、テクニカルサポート、通信販売、予約受付などのインバウンド業務と、商品購入後の調査アウトバウンド業務がある
    • 電話、チャット、Webなどマルチチャンネル対応が必要
    • 地方にコンタクトセンターがあるのは、地方自治体のコンタクトセンターの誘致助成制度が関係している。全205自治体が対象。
    • 九州では福岡、北九州、久留米、長崎、熊本など
    • Amazonのコールセンターも在宅の他、仙台、札幌、福岡
    • 九州は通信販売業が多い土地、コンタクトセンターも多い
    • 通販は売上を左右する
    • おすすめ書籍「コールセンターの全て」
  • Amazon Connectについて
    • Amazon.comで10万人以上が使っているのと同じ技術をそのまま利用可能
    • 提供するサービス範囲は、電話番号、問い合わせフロー、ソフトフォン(ブラウザ上で受電)
    • ブロックをつなぎあわせることで機能を実現
  • コンタクトセンター業界で求められている機能とAmazon Connectで実現できることは「体験」「AI」「データ活用」「在宅」
    • 体験
      • 顧客体験、従業員体験の向上
      • 待ち時間の削減にはコールバック、FAQ、チャットボットの機能が実現できる
      • コールバックはAmazon Connectのブロックの組み合わせで解決、
      • FAQはAmazon KendraとLexを利用して解決
      • 日本語で試したい場合はaws-sampleあり(CDK)
      • 従業員体験の課題、通話中に役立つ情報を表示したい場合はSalesforceと連携することで実現可能
      • Amazon Connectのステップバイステップガイド2023/04提供開始
    • 在宅
      • 働き方改革、コロナ禍による在宅ワークの普及によりニーズが増加
      • セキュリティについては、Amazon Workspaces Workspaces Webと連携することで実現。音声のパケットを別処理することでセキュリティを確保。
    • AI
      • チャットボットAmazon LexやChatGPTなどと連携することで実現
    • データ活用
      • Amazon ConnectのデータはCTRとして保存
      • QuickSightと連携して実現

感想

コンタクトセンターの基礎知識からAmazon Connectの活用方法まで、まさにゼロからわかる非常に勉強になるセッションでした。Amazon ConnectはAmazon TranscribeやAmazon ComprehendなどのAIサービスとも相性が良くまだまだ伸びしろがありそうなサービスですね。

コールセンターだけじゃない!Amazon Connectを使ってできる課題解決いろいろ

  • 登壇者:青柳英明さん
  • 電話対応業務の自動化
    • 電話が次々にかかってきて、本来の業務に支障をきたす、顧客側もなかなかつながらないというストレスを抱えているので、これを自動化によって解決する
    • 電話受付のメニュー化、Amazon ConnectではGUI上で直感的にフロー構築が可能
    • 自動応答を部分的に取り入れる。例外時のみ人が応対する。
    • 既存フローの完全自動化は現実的に難しい。はじめから完全自動化を前提にフローを構築するべき。
  • 発信元電話番号を使って顧客を特定することで付加価値が向上する
    • 活用例
      • 料金案内サービス
        • 発信者番号から顧客IDをもとにデータを取り出して、通知することが可能
      • 予約受付システム
        • 予約日時を顧客入力から取得して、Lambdaを使ってDynamoDBのデータと照合して回答
      • 問い合わせの無人受付
        • 音声の録音方法は2通りある。オペレータとの会話は通話録音機能で可能
        • オペレータを介さない音声はライブメディアストリーミング機能が必要
  • 自動電話発信
    • Amazon Connectで「電話発信」も可能
    • 用途としては、市場調査、世論調査、購入者アンケート、アフターフォローなどのアンケートシステム、リマインダー、
    • 障害通知障害発生時に決められた条件の発信が可能
  • AIの活用
    • ユーザーが質問した内容をLambdaを介してOpenAIへの入力へ変換して、オペレータに回答内容をサジェストするなど

感想

前セッションと合わせてAmazon Connectの知見が一気に拡がりました。具体的な活用例を提示して説明して頂いたのでとてもイメージしやすかったです。

守りの監視から攻めの監視へシフトしよう

  • 登壇者:渡辺聖剛さん
  • 監視の課題は以下の2つ
    • アラートが多すぎて、いざという時に反応できないオオカミ少年問題
    • 完璧にアラートにオンコール対応しすぎる燃え尽き症候群問題
  • これらを「攻め」の監視で解決
    • 守りの最適化
      • 即時対応が必要なものだけにアラートを出す
      • 自動的に復旧させる
        • 自動化とは手動で行う範囲を最小化することで「手作業の回避」が肝である
  • MTTRTB(Mean time-to-return-to-bed)を短くする
    • MTTRTBとは夜中に起こされてからベッドに戻るための平均時間
    • 未知の事象の調査時間を短くするために必要なのは、Observabilityである。
  • リソース監視からサービス監視へ
    • CUJ、SLI/ SLOなどの指標を活用
  • マネージドサービスの積極活用により監視システムの構築を省力化すべし
  • 注意点
    • こうなったらダメ、アウト、それが予めわかっているところへの監視は大切
    • リソース監視はコスト管理の観点でも重要
    • 小さく始めて関係者全員を巻き込む

感想

「MTTRTB」というあまりにも分かりみが深いメトリクスを知れたことが最大の収穫でしたが、それだけでなく、監視も戦略的に行う必要性があるということを学べるとても勉強になったセッションでした。

初心者でもできる!CDKへのコントリビュートについて

  • 登壇者:今泉大樹さん
  • CDKを扱う言語はTypescriptがおすすめ
    • 理由はCDKのソースコードがTypescriptで書かれているため、ネットでの情報もTypescriptが多くGooglabilityが高い
    • ソースコードを見る機会がふえると、改善点が見つかる機会も増える
  • まずはGithubにあるリポジトリをforkする
  • どうやってIssueをみつけるのか、バグはどうやってみつけるのか
    • リポジトリにアクセス
    • Issue一覧を確認(ラベルでIssueをフィルタリング)
  • 初心者向けはコアコントリビューターが初めから修正箇所を指摘してくれている”good first Issue”がよい
  • その他、documentationの修正、軽微なバグの修正なども
  • ローカル開発時の注意点
    • モノリシックなパッケージなので、ビルドが実行できないことがある
    • aws-cdk-libでは自分が修正した箇所のみをビルドすること
    • 開発時は修正した部分だけテストを実行する
    • 課金に注意する
    • AWS Configの検知にも注意

感想

自分はインフラエンジニアなのでソフトウェア周りのことは知見がないのですが、OSSで自分のコントリビュートがグローバルで認められるのは、とてもエキサイティングですし、大きなモチベーションにつながるなと感じました。自分も、いつかCDKくらいならできるかなと想像してしまいました。

コンピュートリソースとトリガーから考えるサーバーレスアーキテクチャ

  • 登壇者:夏目祐樹さん
    • AWSのサーバーレスなコンピュートリソースは、Lambda、Glue Job、Fargateがある
    • Fargate
      • 単体では動かせない
      • ECS、EKS、AWS Batchで使う
    • Glue Job
      • ETL処理特化型でLambdaより強力な実行環境
    • Lambda
      • デプロイパッケージの上限は非圧縮で250MB
      • Container Imageも使用可
    • EventBridgeルールとStepFunctionsはすべてのサービス共通のトリガー
      • EventBridgeルールは定期実行、イベントパターンでトリガー、CloudTrailのAPI Callなどもトリガーになる
      • StepFunctionsは複雑なワークフローを記述/実行するもの
  • コンピュートリソースのトリガー
    • Lambda
      • 豊富
    • Glue Job
      • 備え付けのトリガー
      • EventBridgeルール
      • StepFunctions
    • Fargate(ECS Task)
      • EventBridgeルール
      • StepFunctions
    • Lambdaトリガーの注意点
      • イベントソースマッピング
        • キューからデータをとってきて実行する
        • Lambdaが処理に成功するとキューからデータが削除される
        • Kinesis Data StreamやDynamoDB Streamでは失敗するとデータが詰まらない
        • FIFOでない限りSQSはデータが詰まらない(可視性タイムアウトが重要)
      • 同期実行
      • 非同期実行
      • リトライの仕組みが異なるので注意
      • API Gatewayは29秒以内にレスポンスしないとエラーになることに注意

感想

サーバーレスと言うととりあえずLambdaとなりがちですが、AWSでサーバレスアーキテクチャを組むにしてもコンピュートリソースやトリガーの特性を十分に理解して使いこなす必要があるのだなと改めて理解しました。

マルチアカウント環境で Security Hub を運用する仕組みを作ってみた

  • 登壇者:森田力さん
  • AWS Security Hubをマルチアカウントで利用する際のメリット
    • AWS Organizations を導入せずとも利用可能
  • マルチアカウントで導入時の課題
    • AWSアカウントの担当者がわからない
      • 対策:アカウント情報の設計が必要となる
        • 改善手段:管理単位や担当者情報などを洗い出して、S3、DynamoDBによってDB化する
    • セキュリティスコアが低いままになってしまう
      • 対策:検出結果の扱いを定義する必要がある
        • 改善手段:リスクによって対応方法を変更するなど、どの検出結果を、どう対応するかといった検出事項の扱い方法をDBに登録
  • Step Functionsを使い通知内容によって処理分岐させて通知する
  • 管理者だけでは全アカウントを追うことが難しい
    • アカウントの状態は部署やチームといった全体でセキュリティ意識を高め、お互いを抑制する仕組みづくりが大切

感想

普段の業務ではマルチアカウント環境を扱う機会がなかなか無いので、マルチアカウントで運用する場合の課題は認識しづらいのですが、具体例を挙げて説明されておりイメージしやすかったです。一人の管理者に全アカウント管理を任せるするというより、各部署やチーム単位での取り組みが重要ということを再認識しました。

Kong Gateway から読みとく、API統合・API連携サービスの最新情報

  • 登壇者:田中孝明さん
  • アプリケーションの開発現場は「より複雑に」しかし「提供速度は迅速に」となっている
  • APIが開発するにつれて肥大化した結果、以下のような課題が発生しがち
    • エンドポイントがばらばら
    • パスに統一感がない
    • 別々に認証が必要
    • SOAPとJSONが混ざっている
    • セキュリティがばらばら
    • デプロイ先がばらばら
    • ログ保存先がどこにあるかわかりにくい
  • APIを楽に統合するには
    • APIアグリゲータ(API Gateway)を導入するという手段がある
  • Amazon API Gateway
    • 制限内で利用する場合はベストな選択
    • 29秒以内にリクエストを返す、Payload10MB以内などの制限がある
  • Kongの特徴
    • オンプレミス、クラウドで利用可能
    • GUIで視覚的に設定
    • ライフサイクルAPI管理市場分野のリーダー
    • デジタル庁から推奨
    • DoS攻撃の防止などレート制限
    • ロードバランシング機能
    • AWS とも相性が良く、Kong on AWSワークショップが提供されている
  • Kong Gatewayのプラグインについて
    • OpenID ConnectによりサードパーティIdPとの統合
    • JWTプラグイン
    • Bot Detection
    • サーバーに送る前のリクエストを変換するRequest Transformer
    • クライアントに送る前のレスポンスを変換するResponseTransformer

感想

API GatewayといえばAmazon API Gatewayしか知らなかったので、Kongというサービスがあることを知れたこと自体が収穫でした。また、AWSが公式のワークショップを提供しているほどAWSとの親和性も高そうなので、非常に興味深いProductでした。

成果報告!〜23年新卒ズがスクラム開発やってみた〜

  • 登壇者:小野山翔大さん
  • 新卒社員の研修で、自社社員が使用するアプリケーションを開発
  • 開発したプロダクト Hitome
    • オフィス個人ブースの使用状況を可視化するアプリケーション
    • デスクトップ版とスマホ版を開発
  • チーム開発研修
    • スキルもバックグラウンドも異なるチームでも議論することでとりあえずの方向性は決まる
      • 議論の大切さを学んだ
  • 教える側の学び
    • 実案件では通常3日間おきに行うデイリースプリントを毎日行ったことで、チームの立ち上がりが早かったということで講師側にも学びがあった

感想

さすがトップ企業の新卒研修は素晴らしい内容だなと、感心するとともに、プレゼン自体も非常に分かりやすくまとまっていて話し方も堂々とされており、そんな企業に入社される新卒社員の方の優秀さが光った発表でした。

データ分析における理想と現実……その「なぜ」を解説します

  • 登壇者:甲木 洋介さん
  • クラウド上のデータウェアハウスSnowflakeのSuperHero
  • データ分析の理想と現実
    • 理想はBIツールで自社の課題が可視化されてやるべきアクションが見える
    • 現実はデータ集計をしたもののその結果にピンとこない
  • 自社の問題と課題を把握する。誰が何を知る必要があるか、まで落とし込むことが大事
    • なんとなく始めた分析では、なんとなくの結果しか得られない
    • 「〇〇を知りたい」が分析の出発点
    • ダッシュボードでデータを可視化しても、それを判断できる当事者は誰なのかをはっきりさせることが大事
  • データ把握
    • 理想は欲しい情報が一目でわかる
    • 現実は欲しい情報がどこにあるかわからない
    • データ分析基盤構築前に社内のデータが整理されている必要がある
    • 分析対象以外の情報はメタデータとよび、これらをまとめるものをデータカタログと呼ぶ
    • データカタログ製品はいまトレンドでAWS ではDataZoneなどが該当する
  • 不足情報の補足はオープンデータを利用する、購入するなどの手段がある
  • 最終的にデータ分析は自社で運用できることが必要
  • ダッシュボードには情報詰め込みすぎの傾向がある
    • スクロールが必要なダッシュボードは不要
    • 視点の異なる複数人数で共有するため、別の人から見ると不要な情報が載っているのが問題
    • ダッシュボードの目的は「判断の効率化」である
  • データ構造
    • 理想は欲しい形の情報がすぐに見られる
    • データ構造が変更しづらい
    • データ分析で扱いやすい形式を「整然データ」と呼ぶ
    • DWHに入れるデータは整然データが理想

感想

業界ではよく聞くもののデータ分析自体を実務で携わったことなかったので、データ分析の前段階から説明して頂いたのは非常に理解しやすかったです。「データ分析」という単語が一人歩きしがちなので、何のための分析かをはっきりさせることの必要性がよく分かりました。

まとめ

ブログ掲載が難しい内容もふくまれていたので割愛させていただきましたが、以上のセッション以外にもゲストスピーカーの方のセッションが3つあり、どれも学びの多い素晴らしいセッションでした。

JAWS-UGのイベントにはよく参加してはいるものの、企業様主催のイベントに参加させていただくのは初めての経験でした。経験豊富なエンジニアの方々が業務で得られた知見を社内にとどまらず社外に向けても共有して頂けるのは本当にありがたいなと改めて感じました。こうした機会を提供してくれているクラスメソッドさんにも改めて感謝したいです。

自分も社内外問わず良質なアウトプットをお届けできるようこれからも精進します!