べこの丸太

赤い牛のログです。

【参加レポ】AWSの基礎を学ぼう 温故知新編 基本サービスをみんなで触ってみる DynamoDB #awsbasics

AWSの基礎を学ぼう 温故知新編 基本サービスをみんなで触ってみる DynamoDB

はじめに

こんにちは、べこです。
本記事は、AWSシニアエバンジェリスト亀田さんが主催されている「AWSの基礎を学ぼう」というハンズオンイベントの参加ログです。
今回は待望の新シリーズ「温故知新編」ということで、Amazon DynamoDBを触ってきました。
awsbasics.connpass.com

温故知新編とは?

あるイベントのアンケートの結果、LambdaやDynamoDBなどの基本的なサービスを勉強したいという方が多かったそうです。
そこで、改めてそういうサービスのハンズオンイベントを開こうということで今回「温故知新編」がスタートしました。
次回の時期は未定(1月ごろ?)ですが、Lambda編だそうです。

3行まとめ

  • DynamoDBは分散型Key Value Store(NoSQL)
  • NoSQLと言いつつ、PartiQLというSQL互換のクエリ言語を使うことで、射影、挿入、更新、及び削除が可能
  • DynamoDBも実はトランザクション管理が可能

まずは座学

DynamoDBとは
  • 分散型Key Value Store
    • 単一障害点(SPOF)が存在しない構成のため、可用性が高い。
    • データは3箇所のAZに保存されるため、信頼性が高い。
    • テーブルのパーティショニングは必要に応じて自動的に行われる。
      • パーティショニングの詳細については後述
    • クロスリージョンレプリケーション可能
結果整合性モデル
  • Write
    • 少なくとも2つのAZで書き込み完了の確認が取れた時点でACK(肯定応答)
  • Read(デフォルト、Consistent Read)
    • デフォルト
      • 結果整合性のある読み込み。
      • 最新の書き込み結果が読み取り処理に即時反映されない可能性がある。
    • Consistant Read(強力な整合性のある読み込み)
      • DynamoDBの読み込みオペレーション(GetItem, Query, Scan)にはConsistent Readというオプションがある。
      • Consistent Readオプションを付けると、強力な整合性のある読み込み(Readリクエストを受ける前までの書き込み処理が全て反映された読み込み)を保証。
      • Capacity Unitを2倍消費する。
スループット
  • プロビジョンドスループット
    • テーブルごとに、ReadとWriteのそれぞれに対して必要なスループットキャパシティを割り当てること(= プロビジョニング)が出来る。
    • スループットキャパシティの値はDB運用中にもオンラインで変更可能
      • ただし、スケールダウンに関しては一日に9回しか出来ない。
  • Read Capacity Unit(RCU)
    • 1秒あたりの読み込み項目数 * 項目のサイズ(4KB ブロック)
      • アイテムサイズが4KBを上回る場合、項目のサイズは繰り上げで算出
    • 結果整合性のある読み込み(デフォルト)の場合、スループットが2倍(RCU消費量は1/2)
  • Write Capacity Unit(WCU)
    • 1秒あたりの書き込み項目数 * 項目のサイズ(1KB ブロック)
      • アイテムサイズが4KBを上回る場合、項目のサイズは繰り上げで算出
ストレージ
  • 容量制限がない
  • 使った分だけの従量課金制
  • データ容量の増加に応じたディスクやノードの増設作業は一切不要
パーティショニング
  • DynamoDBはプロビジョンされたスループットを確保するために、テーブルを複数のパーティションに分散して格納している。
  • Partition Keyをパーティション館でのデータ分散に利用
  • 格納ストレージサイズやプロビジョンされたスループットによって自動的にパーティショニングを実施する。
  • スループットパーティションに均等に付与される。
    • プロビジョンされたスループットは各パーティションに均等に付与され、全体で合計値の性能が出るように設計されている。
    • アクセスされるキーに偏りが発生すると、思った性能が出ないということがあるので、Partition Keyの設計には注意が必要(同じ値が何度も入るような設計は避けよう!)
インデックス
  • インデックスが張られていないものを検索対象に出来ない。
  • インデックスはLSI(Local Secondary Index)とGSI(Global Secondary Index)の2種類
  • LSI
    • Sort Key以外に絞り込み検索を行うkeyを持つことが出来る。
    • Partition Keyが同一で、他のアイテムからの検索のために利用する。
    • テーブル作成時にのみ作成可能
  • GSI
    • Partition Keyの代わりとなる。
    • Partition Keyをまたいで検索を行うためのインデックス
    • テーブル作成後に作成
Attributes(属性)
  • 型はスカラー型、セット型、ドキュメント型の3つ
  • Partition Key, Sort Keyの型は、スカラー型のString, Number, Binaryでなければならない。
プライマリーキー
  • 持ち方は2種類
    • Partition Key
    • Partition Key & Sort Key
Auto Scaling
  • 無料で利用可能
  • フルマネージドで、WCU, RCU, GSI(Global Secondary Index)に対する設定を管理
  • 設定は、目標使用率、上限、下限のみ
  • マネコン、CLISDKでの操作が可能
DynamoDB on-demand
  • おすすめの料金オプション
  • 事前のキャパシティプランニングが不要
  • シンプルなAPI操作で設定変更が可能
  • AWSブログはこちら
DynamoDB Streams
  • AWS Lambdaと連携することで、DynamoDBへの書き込みに応じて値チェックをしつつ、別テーブルの更新やプッシュ通知を実行可能
    • テーブルの更新状況の監査ログをS3に保存も可能
  • DynamoDB + AWS Lambda = DynamoDB Triggers
TTL(Time To Live)
  • 無料で利用可能
  • Itemに対し、データベースから自動削除されるタイミングを定義可能
  • プロビジョニングスループットを使用することなく、関連性のないデータのストレージ使用量と保守コストを削減可能
  • 既存・新規のテーブルに設定可能
  • DynamoDB Streamsと併用可能
  • ※注意点あり※
    • 期限切れ後、即削除されるわけではない。
      • 48時間以内に削除
      • 読み取り時に期限切れのものを取得しないようにQueryもしくはアプリ側でのフィルタが必要
DAX(DynamoDB Accelerator)
  • ざっくり言うとキャッシュのようなもの
  • フルマネージドかつ高可用性
  • DynamoDB APISDK)と互換性あり
  • FlexibleでScalable
  • Amazon CloudWatch, Tagging for DynamoDB, AWS Consoleなどとの連携も完備
  • VPC, AWS IAM, AWS CloudTrail, AWS Organizarionなどのセキュリティサービスにも対応
Global Tables
  • マルチリージョン、マルチマスタ
    • 基本的には後勝ちなので、アプリでなんとかする必要あり
バックアップ
  • On-Demand Backup
    • 長期間のアーカイブ及びデータ保持のための規制要件を遵守可能
  • Point-In-Time-Recovery
    • 継続的バックアップ
    • パフォーマンスに影響なし
  • DynamoDBのバックアップは、最近S3にエクスポートできるようになった。
DynamoDB Transactions
  • DynamoDBで複数Item, 複数Tableに対する書き込み操作や読み込み操作でACIDトランザクションが可能
  • トランザクション分離レベルはserializableでロックは取らない。
    • RDSのトランザクションの考え方が少し異なり、ロック中のものに処理をしようとすると例外が発生し、例外を発生させたItem又はTableに関する詳細がThrowされる。

参考:DynamoDBのBlack Belt. https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb

次はハンズオン

このAWS公式ハンズオン をやりました。

また、このハンズオンにはいくつか不備があります。
下記はそれら不備への対応まとめです。

①アプリケーションバックグラウンド.
「ステップ3. サポートコードをダウンロードする。」.
にて、sudo pip install boto3sudo pip3 install boto3 にする.

④項目の更新.
update_item.pyの冒頭に下記3行を追記する。

import boto3
dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
table = dynamodb.Table('Books')
上記ハンズオンでデータ更新までやった後、マネコン上から以下の手順もついでに実施
  • PartiQLエディタを使ってのクエリ実行
    • 本当にSQLライクなクエリ(今回はSelect文)が実行出来た。。。
    • ただWhere句でLIKEを使うと構文エラーが出たため、あくまでも簡易的なクエリっぽい
  • S3へのエクスポート
    • マネコン上から簡単に出来る!
    • 出力形式はjson
インデックスについてのお話
  • インデックスにはインデックスのCapacity Unitを使う。なのでインデックスを増やせば増やすほど料金が上がる。
  • ローカルインデックスはテーブルと一緒に(中に)、グローバルインデックスはテーブルとは別に作られてるイメージ
  • PertiQLでインデックスが張られていない項目に対してwhere抽出すると、実は全件検索してから整形してるので、料金がとんでもないことに。。。検索条件にする項目にはインデックスを張ろう!

次回

次回はこちら.

Lake Formation編も是非!!!

LT感想

Speaker: アイレット株式会社 本間さん

BatchWriteItemを使って26件以上のデータを一気に入れようとすると、エラーが発生。。うおおおおお。。。
それを解決するために、DynamoDB操作アプリを作成!
データ登録〜削除まで、アプリ上の各ボタンで操作出来てました。
イベント当日に作成されたそうww.

おわりに

最新サービスを触るのもいいですが、昔からあるサービスを触るのもいいですね。
今回は座学の時間もあり、SAAやDVAなどの良い復習になりました。
次回の温故知新編も参加します。

【参加レポ】JAWS-UG CLI専門支部 #207R EC2基礎(VPC) #jawsug_cli

JAWS-UG CLI専門支部 #207R EC2基礎(VPC)

はじめに

こんにちは、べこです。
本記事は下記セッションの参加記録です。
下のページの「資料」に丁寧なハンズオン手順書もあるので、興味のある方は是非やってみてください!
jawsug-cli.connpass.com

3行まとめ

  • VPC(Virtual Private Cloud)は、EC2インスタンスを配置するための仮想ネットワーク
  • VPCに関連するAWSリソースが「リージョナルサービス」なのか「AZ依存サービス」なのかを理解することが大事
  • ハンズオンでは、EC2のAPIを使用して、CLIVPC(IGW, ルートテーブル, セキュリティグループ含む)を作成

事前講習

Speaker: 波田野 裕一さん

  • Virtual Private Cloud(以下、VPC)
    • EC2インスタンスを配置するための仮想ネットワーク
    • 他の仮想ネットワークと完全に分離されている
  • Internet Gateway(以下、IGW)
    • リージョナルサービス(AWS側でマネージドされている)
    • VPCと外部ネットワークを繋ぐためのサービス
  • セキュリティグループ

ここからハンズオン

  1. [CloudShell] 今回使用するポリシー(AmazonEC2FullAccess)のアタッチ
  2. [Cloud9] VPCの構築
  3. [Cloud9] インターネットゲートウェイの作成
  4. [Cloud9] インターネットゲートウェイのアタッチ
  5. [Cloud9] ルートテーブルの作成
  6. [Cloud9] ルートの作成
  7. [Cloud9] サブネットの作成
  8. [Cloud9] ルートテーブルの更新
  9. [Cloud9] セキュリティグループの作成
  10. 次回(2021/8/19)、この作成した環境にEC2インスタンスを作成するので、後片付けは無し!

次回はこちら jawsug-cli.connpass.com

おわりに

最近プライベートでVPC作成やEC2作成をCLI構築する機会があったので、今回のハンズオンは非常に良い復習になりました。
VPCやその関連リソースの作成は今後何度も行うと思うので、気が向いたタイミングで改めて復習しようと思います。

【参加レポ】JAWS-UG CLI専門支部 #187R IAM基礎 (ポリシー) #jawsug_cli

こんにちは、べこです。
今回は JAWS-UG CLI専門支部 #187R IAM基礎 (ポリシー) の参加レポです。

jawsug-cli.connpass.com

ざっくり3行

  • IAMの考え方は、権限を「足していく」ではなく「制限していく」
  • IAMポリシーは最大5つまでバージョン違いを設定可能
  • 実際にCLIでIAMポリシーの作成等を行なった

IAMポリシー関連のお話

Speaker: 波田野裕一さん

  • IAMのスタンスは、権限を「足していく」ではなく「制限していく」
  • ポリシーの構成要素
    • 基本はアクションとリソースの組み合せ
      • Effect: Alllow or Deny
      • Action: どういう操作か
      • Resource: どのリソースに対してか(arnで記述する)
    • Efffectの優先順位
      • 同一のアクションやリソースに対して許可と拒否が重複する場合、以下の優先順位で評価される。
      • 1:明示的な禁止(最強)
      • 2:明示的な許可
      • 3:暗黙の拒否(デフォルト値)
  • 最小権限の実現(5W1Hで考える)
    • 誰(利用者)に
    • どこ(リソース)で
    • なぜ(意図)
    • 何をさせたい(アクション)のか
    • を明確にする
  • 最小権限の実装例
  • 2種類のIAMポリシー
    • インラインポリシー
    • 管理ポリシー(2015年ぐらいに新たに追加)
      • AWSは一般的にこちらを推奨

ここからハンズオン

  1. [CloudShell] Cloud9環境のロールにIAMFUllAccessのポリシーをアタッチ
  2. [Cloud9] IAMグループの作成
  3. [Cloud9] IAMユーザーの作成
  4. [Cloud9] APIアクセスキーの作成
  5. [Cloud9] AWS認証ファイルの作成&アクセスキーの削除
  6. [Cloud9] IAMユーザーのIAMグループへの追加
  7. [Cloud9] IAMポリシードキュメントの作成
  8. [Cloud9] IAMポリシーの作成
  9. [Cloud9] IAMグループのポリシーアタッチ
  10. [Cloud9] CLIでの動作確認(list-enviironmentsの実行)
  11. [Cloud9] CLIでの動作確認(describe-environmentsの実行_失敗)
  12. [Cloud9] IAMポリシー(ver.2)ドキュメントの作成
  13. [Cloud9] IAMポリシー(ver.2)バージョンの作成
  14. [Cloud9] IAMポリシーのデフォルトバージョン変更
  15. [Cloud9] CLIでの動作確認(describe-environmentsの実行_成功)
  16. [CLoud9] IAMポリシー(ver.1)の削除
  17. 後片付けは忘れずに!

おわり

今回のCLI専門支部はIAMポリシーのハンズオンでした。
上記ハンズオン手順10にて、認証ファイルを読んでないのに何故か「aws cloud9 list-environments」で
『エラーが出ない!なんでだ〜〜〜〜〜〜!?!?!?!?』
となりました。
なので復讐も兼ねて週末に実施することに。
結果、何故かCloud9環境のロールに "ReadOnlyAccess" が付いてることが原因でした。
どこかのハンズオンで後片付けし忘れたんですかね。
後片付けは大事ですね。。。(反省)

【参加レポ】JAWS-UG CLI専門支部 #186R IAM入門 (ロール)

こんにちは、べこです。
今回は JAWS-UG CLI専門支部 #186R IAM入門 (ロール) の参加レポです。

jawsug-cli.connpass.com

ざっくり3行

  • IAMを制する者は試合(AWS)を制す
  • セキュリティ対策のためにも積極的にIAMロールを使おう
  • 実際にCLIでIAMロールの作成等を行なった

f:id:becominn:20210709002725j:plain

IAMロール関連のお話

Speaker: 波田野裕一さん

  • AWSを真に理解すること = AWS APIを理解すること
    • IAMで使えないAWS APIはほぼ無い!
      • API アクションの数は1万種類以上?
  • AWS学習はIAMに始まりIAM終わる
  • AWS設計はIAMに始まりIAM終わる
  • AWS実装はIAMに始まりIAM終わる
    • IAMを分かってない人はAWSを分かってない人
  • EC2にはIAMロールを直接アタッチ出来ないので、インスタンスプロファイルを挟む
  • IAMロールはAWSリソース同士をつなぐもの
ここからは少しセキュリティのお話
Q. なぜIAMロールを使うのか?
A. クレデンシャル(認証情報)を抜かれるリスクを抑えるため
  • リスク = IAMユーザ * 権限の強さ
    • クレデンシャルを抜かれないように、出来るだけロールを使おう
  • 防御戦略
    • クレデンシャルを抜かれないようにする
    • ユーザープロファイル、APIアクセスキーをなるべく使わない
      • 発行するならMFAによる保護が必要
    • IAMロールをなるべく使う
      • EC2やCloud9を使う
  • 権限戦略
    • 抜かれても被害が少なくなるように権限を制限する
      • 最小権限の原則
ここで波田野さんからの大事なお知らせ!(宣伝)

皆さんも参加しましょう!
私は朝が弱いので寝坊しそうですが、 朝会も頑張って参加します。

ここからハンズオン

  1. 信頼ポリシードキュメントを作成
  2. ロールを作成
  3. 作成したロールにAWSマネージドポリシーをアタッチ
  4. 波田野さんが用意して下さったCloudFormation(以下、CFn)のテンプレートをダウンロード
  5. CFnのテンプレートに対してバリデーションチェック
  6. CFnのスタックを作成
  7. Lambda関数を実行し、IAMロールが動作しているかを確認
  8. CloudWatch Logsのログイベントを取得(filterログイベントは最新日付順じゃない?ので注意)
  9. 最後は後始末を忘れずに!

おわり

今回のCLI専門支部はIAMロールのハンズオンでした。
私自身最近App Runnerを触っていてCLIでのIAMロール作成の重要性を再認識したので、今回はいい復習になりました。
(App Runnerに付けるロールを作成しようとしたんですが、マネコンからは作成出来ないみたいで。。。この話はまた別の記事で書きます。)
CFnのテンプレート作成や実際にCFnを触った経験がほとんど無いため、その辺りも含めて今週末改めて復習しようと思います。

ちなみに、雑コラの作成にめちゃくちゃ時間かかりました。

【参加レポ】AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる AWS App Runner

こんにちは、べこです。
今回は、AWSのシニアエバンジェリスト 亀田さん主催の「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる AWS App Runner」に参加してきました。 awsbasics.connpass.com

最初に注意事項です。
今回のハンズオンは500名近くの方が参加予定でしたが、実際の参加者は300人も居ませんでした。
亀田さんも非常に悲しんでおられました。
本イベントのZoomは、フォージビジョン株式会社 様がご厚意で貸して下さっているものです。
もし参加出来なくなってしまった場合は、直前でもちゃんとイベントページからキャンセルしましょうね。

ざっくり3行

  • AWS App Runnerのハンズオンイベントに参加してきたよ。
  • ハンズオンイベントでは、2通りの方式(github連携、ECR経由)でJavaScriptファイルをデプロイしたよ。
  • 有志LTについて内容を簡単にまとめてみたよ。(各資料への導線もあるので、是非ご覧下さい)

App Runnerって何?

AWS App Runner

aws.amazon.com

  • 2021/5/29 にリリースされたフルマネージドサービス
  • GiHubリポジトリ、もしくはECRのコンテナイメージから超お手軽にWeb Applicationデプロイに必要な環境を全て用意してくれる
  • SSL化やロードバランシング、オートスケーリング、CI/CD設定なんかも勝手にやってくれる
メリット
  • 他のマネージドサービスより超お手軽にフルマネージドな環境が用意出来る
  • GitHubリポジトリからでもコンテナイメージからでもデプロイが可能
  • CI/CD環境がオプションひとつで簡単に構築可能
  • 自動でSSL化される
  • logはCloudWatchに自動で連携
デメリット
  • VPCに配置出来ないため、RDSに安全にアクセス出来ない
    • 本記事執筆時点でDBを使いたい場合はDynamoDBを使うことになりそう
  • 料金が少しお高い
    • これはフルマネージドなサービスなので仕方ない。。。
  • 実際の使用用途があまり思い浮かばない
    • 他のサービスに比べて圧倒的にお手軽なんですけど、「他のサービスに比べてApp Runnerが最も適している!」というユースケースがあまり思い浮かばない。。。
    • あくまでも個人的な感想なので、もし最適なユースケースがあれば教えて頂けると嬉しいです

ハンズオン

それでは本題. 資料も充実してますので、是非やってみて下さい。

事前準備

以下のものを作業前に準備して下さい。

資料

今回は亀田さんがご用意して下さった資料をもとに進めました。

github.com

  • AWS App Runner ワークショップ.pdf
    • ハンズオンのマニュアル
  • Commands.txt
やってみた所感
  • 自分はオレゴンリージョンで実施
    • たくさんの人が同時に実施するのでリージョンを分散させた
  • なんかgithubに接続出来ない。。ぐるぐる回り続けてる。。。と思ったら、CLI系の権限しか無いユーザーでログインしてた
    • ルートユーザーで実施
  • 本当にお手軽にデプロイ出来た
    • 今回デプロイしたものは Hello World!(めちゃくちゃ殺風景な画像を載せてしまった。。。) f:id:becominn:20210704204157p:plain
  • ECRにコンテナイメージをデプロイする際に使うCloud9のインスタンスはt3smallを使おう
その他
  • Cloud Formationのエラーを見るときは「イベント」タブを見る
  • コンテナを実際に運用する場合には、コンテナイメージのtagをgitのコミットIDにするとトレースが楽

やってみたLT

3名の有志の方がLTを行なって下さいました。

AWS App Runner + copilot cli

Speaker : 小木悠斗さん( yuto (@jacoyutorius) | Twitter

speakerdeck.com

こんなお話
  • App RunnerとCopilotを一緒に使うと便利だよ、というお話
    • で、Rubyのワークロードを作ろうとしたらコケたよ、というお話
  • App Runner は楽しい。けど、Copilot と一緒ならもっと楽しい!
  • copilot init でECR登録ぽちぽちが不要!!
  • copilot pipelineは、諸々のパイプライン(githubからの)を自動的に作ってくれる
  • リージョンあたりVPCの制限(最大5つ)には気をつけよう!
結論
  • Dockerfileでファイルをコピーする場合には、ちゃんとディレクトリの最後に / をつけようね
AWS App RunnerでASP.NET Core Webアプリケーションを動かしてみた

Speaker : 木村健一郎さん( しょーちゃん (@show_m001) | Twitter

www.slideshare.net

私も業務ではC#を触ることが多いので、非常に興味深い内容でした。

こんなお話
  • AppRunnerでC#アプリを動かしたよ、というお話
結論
  • コンテナなのでなんでもいけるよね
AWS App RunnerでASP.NET Core Webアプリケーションを動かしてみた

Speaker : mzmtさん( 𝗆𝗓𝗆𝗍👾 (@mzmt1204) | Twitter

こんなお話
  • AppRunnerでRubyアプリをデプロイした時に、ビルドなどで詰まった話
  • 開始コマンドを空にすると、DockerfileのENTRYPOINTのものを使ってくれる
結論
  • デプロイは簡単だったものの、まだまだDB接続面などで課題あり

まとめ

今回はApp Runner(AppとRunnerの間には必ず半角スペース)を初めて触りましたが、本当にお手軽にマネージドな環境をデプロイすることが出来ました。
ただ、個人的に気になってるのはやはりDB周りですね。
RDSを使うには一度AWS外のネットワークを経由しないといけないようです。
RDSではなくDynamoDBを使う形で直近で何かデプロイしてみようと思います。

【参加レポ】JAWS-UG CLI専門支部 #184R EC2入門

こんにちは、べこです。

2021年6月24日開催の「JAWS-UG CLI専門支部 #184R EC2入門」に参加してきたので、そのレポートです。
(前回参加出来なかったので2週間ぶりのCLI専門支部です。)

jawsug-cli.connpass.com

事前に準備したもの

成果

内容

「EC2ハンズオン」

speaker: 波田野さん

 Amazon Elastic Compute Cloud (Amazon EC2) は、アマゾン ウェブ サービス (AWS) クラウドでスケーラブルなコンピューティングキャパシティーを提供します。Amazon EC2 の使用により、ハードウェアに事前投資する必要がなくなり、アプリケーションをより速く開発およびデプロイできます。
Amazon EC2 とは - Amazon Elastic Compute Cloud

  • EC2のAPI

    • EC2
    • Auto Scaling
    • VPC
    • などなど。。。
  • EC2のコマンド数

    • EC2のコマンド数は全部で453。。。(2021年6月24日時点)
    • VPC管理やトランジットゲートウェイの管理などネットワーク関連のコマンドも含まれる
ハンズオン実施
  1. デフォルトVPCの構築*1
  2. ユーザーデータの作成
  3. EC2インスタンスの起動
  4. セキュリティグループへIngressルールを追加
  5. 起動したインスタンスへのアクセス
    • インスタンスのパブリックIPにアクセスすると、コンテンツが表示された! f:id:becominn:20210624193239p:plain

まとめ

VPC等のネットワーク関連のコマンドもEC2のAPIに含まれている、というのが意外でした。 独学でやろうとすると必ず躓いてたな。。。と思いましたねw この知識を得られただけでも、今回のCLI専門支部に参加した価値は十分にあったと思います。 CLIでのEC2インスタンス作成は初めてでしたが、ハンズオンの内容はそこまで複雑ではありませんでした。 波多野さんの素晴らしい資料を参考に、皆さんも是非ハンズオンやってみて下さいね。

*1:私はデフォルトVPCを削除していなかったので存在確認だけ行いました。

【参加レポ】JAWS-UG CLI専門支部 #182R SNS入門

こんにちは、べこです。

2021年6月10日開催の「JAWS-UG CLI専門支部 #182R SNS入門」に参加してきたので、そのレポートです。

事前に準備したもの

成果

  • SNSのトピックを作成し、特定のメールアドレスにメッセージを送信出来た

内容

SNSハンズオン」

speaker: 波田野 裕一さん

  • Amazon SNSとは?

    • Amazon Simple Notification Sevice
    • AWSのPush型メッセージングサービス
    • メール/WebAPI/SQS/モバイル通知などにプッシュ可能
  • SQS vs SNS

    • SQSはPull型(producer → SQS → consumer)
    • SNSはPush型(publisher → SNS → subscriber)
      • pub/sub
      • メーリングリストに近い
      • publisher、subscriberは互いを意識する必要が無い(送り手、受け手の情報を互いに知らなくてもいい)
  • SNSコマンド

    • 全部で43コマンド
  • SNSの要素

ハンズオン実施

諸事情(作業PCの充電切れ)により、ハンズオン自体は後日一人で行いました。

  1. トピックの構築
  2. トピック購買者の追加(サブスクリプション情報の設定)
  3. トピックへメッセージを飛ばす

subscriber側で無事にメッセージを受信!! f:id:becominn:20210614010856p:plain

おわりに

SNSのトピック作成〜メッセージ送信がここまで簡単に出来るだなんて。。。 手順がシンプルだったので非常に理解しやすかったです。 ただ、ハンズオン実施のところから後日再開したためか、トピック構築の際に権限不足でエラーが発生してしまいました。 IAMへの理解を深めるためにも、また日を改めて最初の権限付与の箇所から復習がてら本ハンズオンを実施してみます。