JAWS DAYS 2022 – Satellites｜大阪サテライト会場参加レポート

2022年10月10日2022年10月21日

Contents

1 JAWS DAYS 2022 – Satellites
2 セッション1
3 セッション2
4 セッション3
5 セッション4
6 セッション5
7 セッション6
8 セッション7
9 セッション8
10 セッション9
11 会場の雰囲気
12 まとめ

JAWS DAYS 2022 – Satellites

#jawsdays2022 #jawsdays #jawsug jawsdays2022 jawsdays jawsug jaws-ug

2022年10月08日(土) 3年振りに、Amazon Web Servicesのユーザーグループによって開催され、JAWS DAYS 2022 – Satellites 大阪サテライト会場へ筆者が聴講しにいきましたので会場の雰囲気やセッション内容をレポートします。

セッション1

講義題目	AWS　under　the　hood　～　AWSを中で支えるサービス群について語る　～
発表者	亀田　治伸

エバンジェリスト亀田さんによるAWSを中で支えるサービス群についてLambdaの起源などについてお話がありました、普段サービスを利用する側からは見えてこない、サービスVPC等について聴くことが出来ました。

以下、聴講する中でメモした内容となります。

Lambda　リリース年　2014
　マイクロVM
　Computing　環境をユーザ側が知っておく必要がない
　リリース当初
　SES、Kinesis、DinamoDB、実行時間5分、同時実行数25、1GB、25スレッドであった

　Lambdaの環境を改善するため、開発されたのが、Nitro　System、Fire　Cracker

　Nitro　System
　　ハイパーバイザー、専用VM　軽量KVM
　Fire　Cracker
　　異なるお客様のタスクを同じ物理マシンで実行
　VPC/Databaseへのアクセス
　Lambda　関数の実体
　　マルチAZ実行、単一AZで障害が起きた場合別AZで実行される
　　サービスVPC（自前のVPC）を持っている（ユーザ側からは見られないVPC）

　VPC　HyperPlane　and　V2N
　　仮想化したネットワークプレーン
　　数週間程度のKeppAliveがある

　Lambda　の起動タイプ
　　同期型、非同期型、Event　Source　Mapping　型の3つがある

学びの方程式
　興味　×　義務　×　情熱　＝　結果
　　興味：決めた時間はやってみる
　　義務：アウトプットを最初に宣言する
　　情熱：楽しそうな人にか交わる

セッション2

講義題目	IaCツール徹底比較　~ Slack　botの開発に最も適したIaCツール選手権 ~
発表者	前田　和樹

拡張性、機敏性、運用性の観点から比較がおこなわれ、一位に輝いたのがAWS CDKでした。

AWSのCodeシリーズやSAMとの親和性が高いのが魅力的なようでした。

以下、聴講する中でメモした内容となります。

AWS　CDK
Terraform
AWS　SAM
　サーバレスに特化
AWS　Serverless　Framework
　マルチクラウド対応、サーバレスに特化

SAM/Serverless　Framework
　拡張性
　　CDKが多様なリソースに対応していることから優位
　俊敏性
　　関数の実行確認をローカルで確認することができる

CDK
　cdk　watchコマンドでコードのホットスワップが可能

運用性
　Terraform　CloudのSaaS環境が存在する
　用意な設定でTerraformの実行環境が得られる
　グラフィカルな変更差分で分かりやすい

　Serverless　CI/CD
　　簡単にインフラのCI/CDを構築することが可能

色々な観点でCDKが有利な印象

セッションの中で使用された資料

セッション3

講義題目	AWSマネージドサービスとのテスタブルなアプリケーションコード
発表者	清家　史郎

テストについて筆者自身、想像がつかなかったのでとても参考になりました。

AWSのサービスをローカルでエミュレートすることが可能なlocalstackについて深掘りしていきたいと思った筆者でした。

以下、聴講する中でメモした内容となります。

人はなぜテストをするのか
　不具合は誰も幸せになることが出来ない
　自動テスト
　　UI　テスト
　　Service　テスト
　　Unit　テスト

　Bref
　　AWS　Lambdaで使用可能なフレームワーク

　PHP　Unit
　　「.」、F、Eで結果が出る
　　　「.」：成功
　　　F：失敗
　　　E：エラー

Laravel
　Bref
　　手順をなぞるだけで不自由なくLaravelを構築することが出来る

　ユニットテストの導入
　　MVP（Minumum　Viable　Product）
　　ユニットテストの単位を探す
　　データ処理単位でモデルを作成

　　マネージドサービスのユニットテスト
　　　Mockを使用する方法
　　　　AWS　Mockハンドラーを使用することで疑似結果を返すことが出来る。

Env
　env　ファイルの中には　AWS　認証情報やテスト用の　IAM　を記述することが出来る

マネージドサービスのエミュレート
　S3のエミュレート　
　　MinIO
　　　MinIO　UI
　　　　AWS　SDK　EndPoint　に　MinIO　を指定することでエミュレート可能
　localstackでAWSの主要サービスをエミュレートすることが可能

セッションの中で使用された資料

セッション4

講義題目	Amazon　FSx　for　NetApp　ONTAPで目指す「理想のデータ基盤」！　～強固なデータ保護、高いコスト効率、ハイパフォーマンスの実現～
発表者	藤原　善基

ファイルストレージサービスについてのセッションでした。

k8sの分散ストレージとしてアタッチして使用が可能ということで、参考になりました。

以下、聴講する中でメモした内容となります。

ストレージサービス
k8sの分散ストレージとしてアタッチできる

AWSで満たせなかった要件
　オンプレミスからボリューム単位のクウォータ制限
　高いパフォーマンスとコスト効率を両立した構成
　　自動実行の階層化によるアクセスパターン
　ONTAPの特徴を活かした構成：ユニファイドストレージ

ONTAP　OS
　禁止文字に#をNetBIOS　ドメイン名　/WorkGroup

AWSの各種サービスと連携・統合されており徐々にサポートが増えている
変化する要件に合わせて対応可能、運用負荷の低減が可能

セッション5

講義題目	Amazon　OpenSearch　Serviceで構築するTVerの次世代検索基盤
発表者	黒瀬　祐平

OpenSearchのデータ復元やログ保存アーキテクチャについて気になるセッションでした。

筆者自身、OpenSearchを使用する機会があったので興味深かったです。

以下、聴講する中でメモした内容となります。

Aurora　MySQL
　検索結果　⇒　検索　API
　コンテンツ情報　⇒　CMS

検索の機能を疎結合化
全文検索に特化したミドルウェアの導入

データの管理観点
　MySQLのデータ変更にも柔軟に対応出来る

CMSからのデータをMySQLに格納し、MySQLからデータを取り込むバッチ
　を用意し、OpenSearch側で取り込む

大元のコンテンツ情報の管理はMySQLに委任

取込みバッチは毎回新しいインデックスを作成し、そちらにコンテンツ情報を投入する
古いインデックスは削除する
　インデックスを作り替える毎に参照を更新する必要がある

課題
　可用性の向上、レコメンドなど他の施策との連動

セッション6

発表題目	SRE≠インフラなんだけどもう誤解されちゃってるから、DevOps新実装としてSite　Production　Engineeringはいかがでしょう？
発表者	馬場　俊彰

システムを利用可能かつ"利用可能"かつ"役に立つ"状態にしておくのが「Site　Production　Engineering」らしいです。

DevOpsを実現するためにSREが必要になってきますが、役割の違いを見ると、言いたいことは分かりますね。

正直、ネーミングについて、気にしたことがなかったので良い機会になりました。

セッションの中で使用された資料

--------------------

SREとDevOpsの違い

セッション7

講義題目	AWSのマネージドサービスで実現するニアリアルタイムな検索基盤
発表者	柏木　正隆

全量データ同期や差分データ同期等聞き慣れない用語がでてきました。

検索システムに関する書籍が出ているようなのでいつか読んでみたいと思った筆者でした。

以下、聴講する中でメモした内容となります。

頻度データを検索できるようにするには
　Fargate　検索API　⇒　OpenSearch　検索エンジン
　ETL：Glue
　ワークフロー：パイプライン

　Elasitc　Search　クラスタの運用は考慮ポイントが多く独自で運用しづらい
　全量データと差分データ同期パイプラインでAuroraからOpenSearchへ

　AWS　Glue
　　サーバレス名ETLマネージドサービス
　　差分抽出はCustom　CodeでSQL処理可能

　全量データ同期
　　差分データ同期処理で取り逃がしたデータを同期する
　差分データ同期
　　ニアリアルタイム検索
　　　Job　Bookmark　というオプション機能を利用

　OpenSearch　インデックスの管理
　　インデックスとはドキュメントの集合体
　　インデックス化は検索エンジンが高速に検索できるようにするために必要

全量データの同期中はインデックスが使用出来ず検索できなくなるので
全く同じものをもう一つ用意しておく必要がある

OpenSearch　には　Reindex　APIが存在する

データ同期パイプライン
　ワークフローとパイプライン2つ用意
　　ユーザ辞書、シノニム辞書

インデックス削除　LambdaからOpenSearch　delete　APIを叩く

検索システム　実務者のための開発改善ガイドブック

AWS　SAMによるパイプラインのコード管理

セッション8

発表題目	AWSを用いたフロントエンドモニタリング入門
発表者	水馬　拓也

サーバーサイドモニタリングとフロントエンドモニタリング、フロントエンドモニタリングの観る視点は、異なるようです。

従来の監視サーバ ZabbixやAPM、RUMといった新しい手法について考えさせられる機会となりました。

以下、聴講する中でメモした内容となります。

サーバサイドモニタリングとフロントエンドモニタリングの違い
ユーザ毎にアプリケーションが動作する環境が異なる

エラーログのモニタリング
　Amplify　librarys
　CloudWatch

Amplify　library
　コード内にログ出力設定を行う必要がある
　ログのプレフィックスとログレベル
　ログの発生内容など

CloudWatch　RUM
　ユーザーエクスペリエンスのモニタリング
　　エクスペリエンス情報の出力
　　アプリケーションの健全性情報の取得が出来る
　　Core　Web　Visits　の各種指標情報が分かる
　　アプリケーションのエラーがいつ起こったからなどビジュアライズで分かる

フロントエンドとサーバサイドでモニタリングの観点が異なる

セッションの中で使用された資料

セッション9

発表題目	一緒にAWS　Well-Architectedレビューをやってみよう
発表者	大竹　孝昌

AWS　Well-Architectedフレームワークの考え方について参考になりました。

皆さんは、AWS　Well-Architectedフレームワーク使用しているのでしょうか。

以下、聴講する中でメモした内容となります。

Well　アーキテクテッドフレームワーク
　→　質問集

判定基準について
　→　対象外にできる条件　→　明確な理由がある場合

プロジェクトの方針や条件は明確になっているか
　システムやチームにおける優先順位を定義しているか
　全ステークホルダーと共有できているか
　準拠しないといけない法令等に準拠しているか
　社内ルールを確認しているか

あらゆる障害や失敗にどのように備えているか
　正常性をモニタリングできているか
　モニタリングしているのであればしっかり分析する
　RPO/RTO　SLO/SLI　を定義しているか
　障害の復旧を自動化しているか
　オートヒーリングやDRなど

セキュリティはどのようにコントロールしているか
　システムが保持している情報資産を把握しているか
　世間一般のセキュリティのトレンドを把握しているか
　影響範囲がおおきいもの、起きそうなものを把握しているか
　全レイヤーでセキュリティリスクの対策を実施しているか
　ネットワークアクセスは必要なものに絞っているか
　人とデータを遠ざける仕組みを実装しているか

運用はどのように効率化しているか
　運用タスクを整理し手順書を作成しているか
　自動化が必要な範囲を特定し実装しているか
　タスクを自動化しているか

　システム運用の正常性をモニタリングしているか
　　運用の正常性とはなにか
　　　許容できる作業時間の範囲

パフォーマンスはどのように管理しているか
　パフォーマンスを指標化しテストしているか

コストはどのように管理しているか
　コスト要件を定義しているか
　　予算など

改善や進化はメカニズム化しているか
　実績データをベースに分析や振り返りを行っているか

コスト改善は必要なタイミングが来たらやればよい
　コスト改善のプロセスを継続的に改善しているか

持続可能性の柱は一旦除外して良い