JAWS FESTA 2023 参加レポート

2023年10月7日（土）に福岡工業大学で開催された JAWS-UG 主催の JAWS FESTA に参加してきたので、その参加レポートです。

開催当時の公開情報は以下

JAWS FESTA 2023 KYUSHU

主催:	JAWS-UG (AWS Users Group - Japan)
SNS:	Twitter: @jawsdays, Facebook: jawsug
ハッシュタグ:	#jawsfesta#jawsfesta2023#jawsug

オープニング

#jawsfesta2023 #jawsug

メインテーマは「クラウドどんたく〜会って、学んで、よかろうもん〜」って、福岡の文化と方言と、そしてコミュニティで得られるものが表現されていてめっちゃいいテーマでしょ！と実行委員長の阿部さん。

振り返ってみると、地方でのイベントは、イベント自体が地域で活動している参加者と出会うためのツールだった。

ただ、コロナ禍にオンライン開催できるようにし、支部の活動の存続自体はできたものの、オンラインで参加できるようになってしまった弊害で、地方にいても都市部の情報が得られるようになってしまい、地方支部の存在意義が薄れてしまった。

そもそも JAWS FESTAとは

中央（都市部）で行われる JAWS DAYS の対局に位置していて、JAWS FESTA は地方の JAWS-UG が主催するコミュニティイベント

パネルディスカッション「地方コミュニティの存在意義とは？」

パネリスト

• 立花さん
  2010 年は京セラドーム（の横のチューブのところ）で開催した。ICDP＝田舎クラウドデザインパターンのお題でセッションを実施されたとのこと
• 松村さん
  どちらかというともう一つの A がつくクラウドをよく使っておられる。
  福岡.NET（通称ふくてん）もやっている。
• 家壽田（けすだ）さん＝「けっすー」
  関東で 20 年勤めてたけど、関東を捨てて、福岡にいらっしゃる。G のつくクラウドのエンタープライズ系のユーザー会に所属されている。（エバンジェリスト）

モデレータ

• iret の鈴木さん
  いろんな地方のコミュニティに参加されてて、フッ軽でマジですごい人だわ。（感想）

テーマ：そもそも地方でコミュニティを運営する意味はあるのか？

Note

以下、会話の記録としてメモしていたので、出来の悪いインタビュー記事っぽくなってしまっている点に注意

鈴木さん：元々都内、都市部で開催されたコミュニティイベントでの発信内容が、地方に伝播していく性質を持っていたのかな？と思われる中、オンラインでつながるようになってしまった現在、地方でコミュニティ運営をすることの意味について語ってほしい。

立花さん：オンラインとの比較として、情報の方向がオフラインだと双方向である点が違う。オンラインだと一方通行になってしまう。
また、同じ地域に住んで同じ課題感を持っている人たちが集まっているところが良い。
正直、苦労は多いが、仕事ではないので、嫌ならやめればいいし、また再開してもいいし。
ただ、普段接しない人たちと関わることができるメリットがある。
また、コミュニティにコントリビュートしている人たちは幸福度が高いという研究結果もあるし、そもそも、社会人になってから、こんなに全国各地に友達ができることって少ない。

松村さん：運営する意味はある！
コロナ前後比較しても意義はあると経験も含めて言える。
参加目的として、最新情報や事例を聞く、シェアする目的もあるが、オンラインだとセッション終わった後は、そのまま終わりになってしまう。反面、オフラインだと、セッション後に Ask The Speaker 的に話しかけてもらえたり、その後の広がりがある。
仲間が増える。
盛り上がりや熱量が上がる。

鈴木さん：いろいろなコミュニティに顔を出すようになってから、普段自分が意識していないことにも興味が向くようになってきて、自分のアンテナが広がっていると感じている。

けっすーさん：ぶっちゃけると自社を広めたい！勘定系をクラウドでやってるぞ！という会社があるんだということを広めたい、というモチベーション。
地元を大事にしないとなかなか人が採れない。
固い話をすると人間関係を作るのも大事だし、一回来てくれた人が数回来てくれた後、結局フェードアウトしてしまってたりと、なかなか継続的にならないところはある。

互いに質問タイム

立花さん→お二人：福岡は IT が盛り上がっているイメージがあるが、九州内の他の地域との差は？

松村さん：場所作りに自治体が後押ししているところもあるが、以前からコミュニティはあって、エンジニア文化として根付いている土壌はある。

けっすーさん：適材適所で（ここ聞き逃してしまってるな…）

鈴木さん→立花さん）東北は？ > IT 産業への支援に対して、行政側の担当者の熱量の差によって温度差が生まれがちなところはあるかもしれない。

松村さん：エンジニアカフェがあった点のメリットとしては「場所」問題が解決した。ハブになっている。
ただし、福岡の状況としては、上場企業が少ない問題はある。

松村さん→立花さん）JAWS は各拠点が自走しているイメージがあるが、そのモチベーションは？

立花さん：元々、首都圏で行われていたイベントを地方に伝播する役割があったが、徐々に、専門支部が生まれ、分科会が広がってきた。
ただし、次の世代にバトンを渡したいけど、後継者問題はある。

けっすーさん：始めたばかりだからまだその問題は（後継者問題）ないが、内輪感が出てしまわないようにはしたい。

松村さん：一緒に盛り上げてくれる人が増えてくれると嬉しい。そして関わってみたいと思った人が増えるとなお良い

地方のコミュニティイベントに参加する人たちに期待するアクションは？

けっすーさん：一つくらいは自分と全く関係ないセッションを受けてほしい。広く知る良い機会。
もし、ちょっと違ったな？と思っても参加し続けてほしい。
もしも、参加し続けて違和感があるのであれば、運営に回ってほしい。

松村さん：仲間作りをしてほしい。
イベントに来る＝インプットなので、何かしらアウトプットしてほしい。
そして、楽しそうと感じたら、イベントを作る側に回ってほしい。

鈴木さん：JAWS で昔からよく言われている言葉に「アウトプットしないのは知的な便秘」がありますね。

立花さん：JAWS で言われているもう一つの格言に「100回の参加よりも1回の登壇」というのもあるので、是非是非登壇をしてみてほしい。
グローバルにつながっている。
仕事で海外に出て行くことは難易度が高いが、コミュニティを通じて海外に出て行くことは意外にハードルがそこまで高くないとのこと。
実体験として、AWS Summit Seoul に呼ばれた際に、それっぽいテーマを話そうかと思ったら、日本での経験を話してほしいとの依頼。
なぜ韓国に行って青森の話をしなければならないのか半信半疑だったが、終わってみたら、スタンディングオベーション。
のちのち聞くと、韓国は日本以上にソウル一極集中なので、真逆の活動をしている立花さんの話が韓国の地方の人に刺さった→そして、この経験は、今の立花さんの仕事を推進する自信に繋がったとのこと。

鈴木さん：立花さんの話に「グローバル」というキーワードが出たが、グローバルなつながりは？

松村さん：MS のアワードでのつながりで、MS の中の人とかと交流する機会はある。
あと、立花さんと会話をしていて、SDK に不具合があった場合、「リポジトリに issue を投げる」という行為も、もうグローバルに出ていっていると言えるよね、と感じた。

けっすーさん：Jagu'e'r では NDA の関係もあり、日本企業しか所属していないが、他のエバンジェリストでは繋がりを持っている人もいる。
ご本人的には、英語ができないので消極的になりがちだが、あまり臆さずに接したいと考えている。

聴講側から質問

福岡や仙台などと近県との関わり合い方について？（関東近郊でも 東京 ＞ 千葉支部 の図式がある点がご質問背景）

けっすーさん：Jagu'e'r は2年程度しかやっていないためまだ、地盤がためをしているところがある。
NDAの関係で、基本的にはクローズドにならざるを得ない部分があるが、学生向けのハンズオンなども企画しても面白いだろうなぁとは思っている。
その先に、長崎や大分に来てもらうのか行くのかは別として広めていかないといけないなとは思う。

松村さん：コロナも理由の一つだが、地方に行って話をする場を何回か持ったが、結局その後継続しなかった。
やはり、人が集まりづらい問題はあるが、まずは福岡は福岡で集まれる場所を継続し続けることが大事だと思っている。

立花さん：東北も同じ問題を抱えているが、元々各県でやっていたものを一つにまとめて、支部の中で各県で話し合って決めている。

山下さん→けっすーさん：出張費出せるように招聘するからどんどん来てくれ、とのことだがどのようなことにニーズがある？

Google クラウドを使っている、あるいはハイブリッドしているような連携している事例などを話してもらえると嬉しい。

他社とコラボした事例などがあるか？

けっすーさん：Jagu'e'r ではそこまではない。比較的レガシーな会社が DX を進めた事例を記事にしてくれて、地元にこんな会社があったんだという気づきはある。

松村さん：ベンダー主導の色は強かったが、パートナー間で連携した例はあった。

立花さん：コミュニティを通じてM＆Aまでしてしまったのでコラボどころではないがw
東京の案件の下請けをしている仕事が地方ベンダーには多いが、経歴や事例がレガシーなので、請られない状況がある。
そこで、地域のベンダー自体で内製化ができるように、地域の会社さんにコンサルするような形で活動したりしている。（そこで経歴や事例を持って、東京の案件を請けられるようにしたいという思い）

感想

「一つくらいは自分と全く関係ないセッションを受けてほしい。広く知る良い機会」は、JAWS の大きめのイベントや、AWS 公式のイベントにおいて聴講セッションを選択するときの目線が、なんとなく知っている分野とかを選びがちだったので目から鱗。今後の行動の指針にする。

---

数百以上の様々なbatchが動いているバッチ基盤をECS on FargateからEKS on EC2へ移行した話

登壇者

• 株式会社エウレカ（マッチングサービス Pairs の運営会社さん）：笹本さん

• 美味しいサバとイカを食べて帰る

セッション概要

背景

プッシュ通知、審査処理、ElasticSearch のドキュメント更新を行うバッチが存在していて数にして 332。
Pairs は日本以外のリージョンでも展開・利用しているので、実質 332 × 3 リージョン存在していた。
また、バッチの種類は以下の 2 種類があった

• スケジューリング型（Cronによる定期的なもの）
• メッセージレシーブ型

移行前

EC2 にcrontab を置いていた時代を経て、ECS on Fargate で実行している。

アドホックな実行も可能としていた。

他の検討としてLambda や AWS Batch も検討したがそれぞれ以下の利用で見送り

• Lambda：15分の制約に引っかかってしまう
• Batch：メッセージレシーブ型のバッチに対する改修コストが大きかった

移行前の問題点

• メッセージレシーブ型のジョブにおいて Lambda でタスク数を計算していた ← 常に、Quota への考慮が求められている
• GuardDuty のコストが大きい
• Fargate ではコンテナイメージのキャッシュができない
• バッチの数が増えるとコンピューティングリソースがコストがかかる。
  Fargate では EC2 より大きくなりがち
• すでに、アプリ基盤で EKS on EC2 基盤の導入があり、管理を同様にしたかった

移行後

マニフェストのテンプレート化のために CUE 言語を採用した。

実質一行でバッチを作成可能とした。

バッチ作成体験の向上（背景技術等をカプセル化する感覚で学習コストやコミュニケーションコストの削減につながった。

k8s で運用する際の注意点

処理が終了した pod は削除する→IPの消費、枯渇につながる

どちらがいいか

結局ケースバイケース

感想

EKS on EC2 のメリットはありつつも、EKS 独自の学習コストは低くなく、全体的な EKS の運用・管理の規模がどの程度かで考えた方が良いとの意見について理解した。

CUE 言語とはなんなのか調べてみる。

---

佐賀銀行におけるクラウドジャーニー〜AWS未経験から本番システムの内製構築まで、および今後の展望〜

#jawsfesta2023_B #jawsfesta2023 #jawsug

登壇者

• 株式会社佐賀銀行 平島さん
  DX 推進を担当している部署にお勤め。

セッション概要

前提として、スピード感を求めるために内製化する選択をした。その時に親和性が高いクラウド化を選択した。

ただし、クラウド導入にあたっては障壁も多く、概ね以下のような流れで行った。

• 経営層向けの説明と合意
• この時は AWS 以外のクラウドで話をしていた
• Udemy を利用したオンライン研修
• 仕事中の閲覧、自宅での閲覧も可とした
• Fusic 社の研修
• 認定資格の取得
• 他行への派遣
• 内製開発の着手

また、経営層向け AWS プログラム参加し、経営層の意識の引き上げをした。

今後の課題は、Amazon Connect の導入やサーバレスの導入

対象の業務は、行内業務からクラウド・内製化を行った。申し込み書類がどこまで回っているかを見える化するアプリを構築。

先進行から提供を受けたものを独自にカスタマイズし、先進行では SMS 送信していたものを、Teams にも送信できるようにしてコスト削減化などの工夫を実施。

気づきとしては、AWS では全世界的な利用がされているので、佐賀銀行で思いついた機能やシステムはすでに国内外問わずすでに似たようなことを実施している企業がある点。

感想

事例として、クラウドを導入してく過程や、対象とした業務について詳細に伺えて良かった。

銀行同士で連携して教えを乞いにいって、そして先進行が快く応じているという事例もあるのだと思った。（ゴリゴリライバル視とかがあるのではないか？との意味で）

---

アプリケーションログ、どう出力する？　どう調査する？

#jawsfesta2023_A #jawsfesta2023 #jawsug

登壇者

• フェンリル株式会社：森井さん

セッション概要

前提

AWS 上で動くモノリシックアプリケーションシステムを対象としている

セッション概要

不具合発生時によくある例

• 調査に時間がかかったり、不具合が解消できずに、ユーザー満足度が落ちる
• 問い合わせは一件でも、実は裏に同じ症状が発生しているユーザーが多くいるかもしれない。
• そして、多くのユーザーは問い合わせせずサービスを使うのをやめてしまう。

ログ調査時の問題点

• チームに長くいるシニアエンジニアの勘と経験頼りとなってしまう

重要な項目

• オブザーバビリティ＝可観測性＝外部出力の知識からシステムの内部状態をどの程度推測できるかを示す尺度

• 適切なログレベルの設定

• 非構造化ログから構造化イベントログへ
  ログを検索しやすい形式にする、断片的な情報にせず、すべてのイベントを記録する
  PHPであれば Monolog の JsonFormatter を導入するだけで対応可能

• 構造化イベントに追加する情報を決める
  ユニークな値を持つ情報を記録しよう。ユーザー ID など一意に定まる情報を記録する。
  出せる限りのすべての情報を記録したいところだが、システムの状態を理解するのに必要な情報範囲を決める。
• トレース情報を追加する
  複数のサービスで連携してリクエストを処理するため、各サービス間の個別のログを連続的に（横断的に）記録するトレース ID を含めておく。
  これがないと「時系列的にこの辺だろう？」というアタリの付け方しかできない。

アプリケーションログをどう調査する？AWS でログ閲覧・解析に利用できるサービス

• Amazon Athena
• CloudWatch Logs
• Amazon OpenSearch Service

まずは、CloudWatch Logs から始めるのが良いが、コストが高くなりがち。

感想

普段の自分の業務から言っても、適切なログの存在はとてもありがたい。

ログ設計（何を出力するか、頻度、アプリ間の関連性）が重要だという意識は広まってほしいと切望。

---

AWSいまどきの監視事情 - CloudWatchのその先に -

#jawsfesta2023_A #jawsfesta2023 #jawsug

登壇者

クラスメソッド株式会社：渡辺さん

セッション概要

CloudWatch サービス多すぎ

その他新顔

• Code Guru Profiler
• DevOps Guru
• Compute Optimizer

個人的には、X-Ray や Performance Insight は CloudWatch に寄せていく傾向があるのでは？と思っているとのこと

他にも

• CloudWatch Lambda Insights
• CloudWatch Contributor Insights
• FireLens for ECS
• CloudWatch Container Insight

また、CloudWatch 以外では、Route53 のヘルスチェック機能を使えば、Ping を投げたい、のような単純な監視に使える

そして、従量課金 × 円安なのでコスト管理は重要！

クロスリージョンやクロスアカウントの構成でも、クロスアカウントクロスリージョン CloudWatch ダッシュボードがある。

CloudWatch Metric Streams＝CloudWatch に送信されたメトリクス情報を Kinesis Data Firehose に転送する機能

登壇まとめ

• AWS には運用監視に役立つ機能が大量にある
• カオスになる前に代替案の検討を

サービスのリリース〜運用・監視は「短距離走ではなく、マラソンである」

感想

確かに、CloudWatch のサービスはどんどん増えている印象。
キャッチアップをしないと…。

そして、「短距離走ではなく、マラソンである」は真理。

---

The Right Tools for The Right Job 時はベンダー戦国時代！AWSと相性が良いのは誰だ？！

#jawsfesta2023_E #jawsfesta2023 #jawsug

一人目は Momento の KOITABASHI Yoshitaka さん

Momento は、開発者を助ける最高のサーバレスプラットフォーム

Momento Cache DBとアプリの速度を上げるソリューションで AWS との位置付けは概ね以下のとおり

• ElastiCache
• Amazon DynamoDB Accelerator (DAX)
• そして Momento Cache

他に、Momento Topics（Pub/Sub）、Momento Vector Index も用意されている。

ご意見番からの質問

「キャッシュ」というキーワードで、非エンジニアを相手にした場合、どのように説明する？

• 今動いているWEBサービスの速度を上げたくないですか？
• マッチングアプリを作りたくないですか？

軽く、ご宣伝 → Momento Big Fun

二人目は Snyk の FURUYAMA Sanae さん

Snyk は So, Now You Know の略

Snyk は DevSecOps の実現をサポートする。「迅速な開発」と「セキュリティ」の両立を支援。

みんなのためのセキュリティプラットフォームとは？

• 「自分のこと」として考える
• 「チーム」として考える
• 「他のチームの立場」を考えて行動する

アプリコードだけでなく IaC もガンガン修正できる。

パイプライン管理の立場では？Code Build のビルド先に Snyk の選択肢ができている

また、Amazon Inspector の脆弱性のデータベースエンジンは Snyk だったりする。

Snyk の課金体系は、コードの量ではなく、コードを書いている人のユーザー数での課金

三人目は Cloudflare の KAMEDA Harunobu さん！

タイトルは攻めた感じの 「私がいる、それ以外に理由が必要？ ～AWSを７年半、中から見た男が選んだCloudflare」

ひさびさの亀田節。

Cloudflare は AWS のライバルになりうるのか？
→少なくとも、向こう 3 年はそれはない。それよりもインターネットが汚れすぎているので、まずは安全にインターネットを使える状況にすることが先決

また、AWS がリリースしているセキュリティ系のサービスを的確に利用することで、AWS サービスのみで高いセキュリティを獲得することは可能だが、おそらく、すべてのセキュリティ系サービスについて、網羅的に、かつ深く理解しているユーザーが少ないと考えられるため、Snyk などのサードパーティの製品の導入は現実的かも、と元内部の方として貴重なご意見も。

感想

そもそも、キャッシュの役割についてピンときていなかった部分もあったので、Momento Cache にしても ElastiCache や DAX についても一度ハンズオンなどをやってみよう。

Synk については、Amazon Inspector の脆弱性のデータベースエンジンに使われているとのことだったので、これもまた調べてみる。

そして、久しぶりに亀田節が聞けたのは嬉しかった。向こう 3 年くらいは敵にならないとのことなので一安心。

全体的な感想

JAWS FESTA は初めての参加だったが、コロナ禍で開催できない期間の鬱憤を晴らすかのように、熱量のあるイベントだった。

上記には書いていないが JAWS FESTA お茶会テーブル というイベントも企画してくれていて、九州中のお菓子と八女茶を飲みながら4〜5人ひとグループでお茶会をするというイベントは、普段懇親会でお酒が入ってからしか初めましての人と会話をしない傾向のある自分にとっては面白いイベントだった。

また大学での開催ということで、大きいステージでも見やすかったし、学食で食事が取れるというのも良かった。

一番の収穫は、オープニングセッションでの家壽田（けすだ）さんの「一つくらいは自分と全く関係ないセッションを受けてほしい。広く知る良い機会」というご発言。
JAWS の大きめのイベントや、AWS 公式のイベントにおいて聴講セッションを選択するときの目線が、なんとなく知っている分野とかを選びがちだったので目から鱗。今後の行動の指針にしたい。

懇親会では、自社のお会いしたことないメンバーと対面でお会いできたことも良かった。

ゴロゴロといる猛者たち（ゴールドジャンパーや古参メンバー）に臆することなく今後もいろんなイベントに参加して行きたいし、今回懇親会 LT は落選したが、手を挙げることを続けて行きたい。

あと、中洲のガールズバーで初めて 1対N という女の子の人数が多いという現象を体験。これはこれで、どちらにも均等に話しかけないといけない圧力みたいなものを感じて、居心地の良いものでもないと実感。

あっという間の滞在だったので、福岡にはまたゆっくりと行く。

あと、運営メンバーには本当に感謝！

Comments