究極のトマトパスタ
久しぶりにこのブログに記事を投稿するんですが、技術関係無いです。美味い飯の話です。
ということで、この記事は バズレシピ Advent Calendar 2022 - Adventar 21日目の記事です。
僕が紹介するのはこれ↓
【パスタ世界一が教える】フレッシュトマトで革命的な美味しさ トマトソースパスタの作り方【 #弓削啓太のパスタ道 vol.4】クラシル #シェフのレシピ帖
はい。具材はミニトマト！ニンニク！バジル！以上！
最高にシンプルで最高に美味いトマトパスタです。
超簡単なので自分は夜食として時々作ってます。
アレンジ
ちなみに最後に乗せるフレッシュなトマトを少量の塩、オリーブオイル、バジルでマリネしておくのが個人的にはおすすめです。
ミニトマトからいい感じに水分が出てちょっとしたソースっぽくなる。
我が家の作る手順
我が家作る手順は↓
- ミニトマトを切る（全体の7割を1/2カット、3割を1/4カット）
- 1/4カットのミニトマトをマリネ（少量の塩、オリーブオイル、バジル）して冷蔵庫で冷やす
- パスタを茹で始める
- 1/2カットのミニトマトとニンニクをオリーブオイルで良い感じに焦げ目がつくまで炒める（動画参照）
- 4のフライパンに茹でたパスタを投入。良い感じに和えたら火を止めてバジルを混ぜて軽く煽る。
- パスタを皿に盛り付け、マリネしておいたミニトマトをかけて完成。最後にお好みでトッピング。
モッツァレラチーズは合うので乗せるべし
この画像は今日作ったやつ。我が家ではよく生ハムとモッツァレラチーズをトッピングします。
生ハムは無くても良い（トマトだけで十分美味い）んですが、モッツァレラチーズはマジで合うのでおすすめ。
【参加レポ】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
結果整合性モデル
- Write
- 少なくとも2つのAZで書き込み完了の確認が取れた時点でACK（肯定応答）
- Read（デフォルト、Consistent Read）
- デフォルト
- 結果整合性のある読み込み。
- 最新の書き込み結果が読み取り処理に即時反映されない可能性がある。
- Consistant Read（強力な整合性のある読み込み）
- DynamoDBの読み込みオペレーション（GetItem, Query, Scan）にはConsistent Readというオプションがある。
- Consistent Readオプションを付けると、強力な整合性のある読み込み（Readリクエストを受ける前までの書き込み処理が全て反映された読み込み）を保証。
- Capacity Unitを2倍消費する。
- デフォルト
スループット
- プロビジョンドスループット
- Read Capacity Unit（RCU）
- 1秒あたりの読み込み項目数 * 項目のサイズ（4KB ブロック）
- アイテムサイズが4KBを上回る場合、項目のサイズは繰り上げで算出
- 結果整合性のある読み込み（デフォルト）の場合、スループットが2倍（RCU消費量は1/2）
- 1秒あたりの読み込み項目数 * 項目のサイズ（4KB ブロック）
- Write Capacity Unit（WCU）
- 1秒あたりの書き込み項目数 * 項目のサイズ（1KB ブロック）
- アイテムサイズが4KBを上回る場合、項目のサイズは繰り上げで算出
- 1秒あたりの書き込み項目数 * 項目のサイズ（1KB ブロック）
ストレージ
- 容量制限がない
- 使った分だけの従量課金制
- データ容量の増加に応じたディスクやノードの増設作業は一切不要
パーティショニング
- DynamoDBはプロビジョンされたスループットを確保するために、テーブルを複数のパーティションに分散して格納している。
- Partition Keyをパーティション館でのデータ分散に利用
- 格納ストレージサイズやプロビジョンされたスループットによって自動的にパーティショニングを実施する。
- スループットはパーティションに均等に付与される。
インデックス
- インデックスが張られていないものを検索対象に出来ない。
- インデックスはLSI（Local Secondary Index）とGSI（Global Secondary Index）の2種類
- LSI
- Sort Key以外に絞り込み検索を行うkeyを持つことが出来る。
- Partition Keyが同一で、他のアイテムからの検索のために利用する。
- テーブル作成時にのみ作成可能
- GSI
- Partition Keyの代わりとなる。
- Partition Keyをまたいで検索を行うためのインデックス
- テーブル作成後に作成
Attributes（属性）
プライマリーキー
- 持ち方は2種類
- Partition Key
- Partition Key & Sort Key
Auto Scaling
- 無料で利用可能
- フルマネージドで、WCU, RCU, GSI（Global Secondary Index）に対する設定を管理
- 設定は、目標使用率、上限、下限のみ
- マネコン、CLI、SDKでの操作が可能
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 API（SDK）と互換性あり
- 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 boto3 → sudo 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抽出すると、実は全件検索してから整形してるので、料金がとんでもないことに。。。検索条件にする項目にはインデックスを張ろう！
次回
次回はこちら.
- 11/06（土） 13:15〜15:15.
AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Prometheus.
Lake Formation編も是非！！！
- 11/20（土） 10:00〜12:00.
AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる 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を使用して、CLIでVPC(IGW, ルートテーブル, セキュリティグループ含む)を作成
事前講習
Speaker: 波田野 裕一さん
- Virtual Private Cloud(以下、VPC)
- EC2インスタンスを配置するための仮想ネットワーク
- 他の仮想ネットワークと完全に分離されている
- Internet Gateway(以下、IGW)
- セキュリティグループ
ここからハンズオン
- [CloudShell] 今回使用するポリシー(AmazonEC2FullAccess)のアタッチ
- [Cloud9] VPCの構築
- [Cloud9] インターネットゲートウェイの作成
- [Cloud9] インターネットゲートウェイのアタッチ
- [Cloud9] ルートテーブルの作成
- [Cloud9] ルートの作成
- [Cloud9] サブネットの作成
- [Cloud9] ルートテーブルの更新
- [Cloud9] セキュリティグループの作成
- 次回(2021/8/19)、この作成した環境にEC2インスタンスを作成するので、後片付けは無し！
次回はこちら jawsug-cli.connpass.com
おわりに
最近プライベートでVPC作成やEC2作成をCLI構築する機会があったので、今回のハンズオンは非常に良い復習になりました。
VPCやその関連リソースの作成は今後何度も行うと思うので、気が向いたタイミングで改めて復習しようと思います。
【参加レポ】JAWS-UG CLI専門支部 #187R IAM基礎 (ポリシー) #jawsug_cli
こんにちは、べこです。
今回は JAWS-UG CLI専門支部 #187R IAM基礎 (ポリシー) の参加レポです。
ざっくり3行
- IAMの考え方は、権限を「足していく」ではなく「制限していく」
- IAMポリシーは最大5つまでバージョン違いを設定可能
- 実際にCLIでIAMポリシーの作成等を行なった
IAMポリシー関連のお話
Speaker: 波田野裕一さん
- IAMのスタンスは、権限を「足していく」ではなく「制限していく」
- ポリシーの構成要素
- 基本はアクションとリソースの組み合せ
- Effect: Alllow or Deny
- Action: どういう操作か
- Resource: どのリソースに対してか（arnで記述する）
- Efffectの優先順位
- 同一のアクションやリソースに対して許可と拒否が重複する場合、以下の優先順位で評価される。
- １：明示的な禁止（最強）
- ２：明示的な許可
- ３：暗黙の拒否（デフォルト値）
- 基本はアクションとリソースの組み合せ
- 最小権限の実現（5W1Hで考える）
- 誰（利用者）に
- どこ（リソース）で
- なぜ（意図）
- 何をさせたい（アクション）のか
- を明確にする
- 最小権限の実装例
- 2種類のIAMポリシー
- インラインポリシー
- 管理ポリシー（2015年ぐらいに新たに追加）
- AWSは一般的にこちらを推奨
ここからハンズオン
- [CloudShell] Cloud9環境のロールにIAMFUllAccessのポリシーをアタッチ
- [Cloud9] IAMグループの作成
- [Cloud9] IAMユーザーの作成
- [Cloud9] APIアクセスキーの作成
- [Cloud9] AWS認証ファイルの作成＆アクセスキーの削除
- [Cloud9] IAMユーザーのIAMグループへの追加
- [Cloud9] IAMポリシードキュメントの作成
- [Cloud9] IAMポリシーの作成
- [Cloud9] IAMグループのポリシーアタッチ
- [Cloud9] CLIでの動作確認(list-enviironmentsの実行)
- [Cloud9] CLIでの動作確認(describe-environmentsの実行_失敗)
- [Cloud9] IAMポリシー(ver.2)ドキュメントの作成
- [Cloud9] IAMポリシー(ver.2)バージョンの作成
- [Cloud9] IAMポリシーのデフォルトバージョン変更
- [Cloud9] CLIでの動作確認(describe-environmentsの実行_成功)
- [CLoud9] IAMポリシー(ver.1)の削除
- 後片付けは忘れずに！
おわり
今回のCLI専門支部はIAMポリシーのハンズオンでした。
上記ハンズオン手順10にて、認証ファイルを読んでないのに何故か「aws cloud9 list-environments」で
『エラーが出ない！なんでだ〜〜〜〜〜〜！？！？！？！？』
となりました。
なので復讐も兼ねて週末に実施することに。
結果、何故かCloud9環境のロールに "ReadOnlyAccess" が付いてることが原因でした。
どこかのハンズオンで後片付けし忘れたんですかね。
後片付けは大事ですね。。。（反省）
【参加レポ】JAWS-UG CLI専門支部 #186R IAM入門 (ロール)
こんにちは、べこです。
今回は JAWS-UG CLI専門支部 #186R IAM入門 (ロール) の参加レポです。
ざっくり3行
IAMロール関連のお話
Speaker: 波田野裕一さん
- AWSを真に理解すること = AWS APIを理解すること
- AWS学習はIAMに始まりIAM終わる
- AWS設計はIAMに始まりIAM終わる
- AWS実装はIAMに始まりIAM終わる
- IAMを分かってない人はAWSを分かってない人
- EC2にはIAMロールを直接アタッチ出来ないので、インスタンスプロファイルを挟む
- IAMロールはAWSリソース同士をつなぐもの
ここからは少しセキュリティのお話
Q. なぜIAMロールを使うのか？
A. クレデンシャル(認証情報)を抜かれるリスクを抑えるため
- リスク = IAMユーザ * 権限の強さ
- クレデンシャルを抜かれないように、出来るだけロールを使おう
- 防御戦略
- クレデンシャルを抜かれないようにする
- ユーザープロファイル、APIアクセスキーをなるべく使わない
- 発行するならMFAによる保護が必要
- IAMロールをなるべく使う
- EC2やCloud9を使う
- 権限戦略
- 抜かれても被害が少なくなるように権限を制限する
- 最小権限の原則
- 抜かれても被害が少なくなるように権限を制限する
ここで波田野さんからの大事なお知らせ！（宣伝）
皆さんも参加しましょう！
私は朝が弱いので寝坊しそうですが、 朝会も頑張って参加します。
ここからハンズオン
- 信頼ポリシードキュメントを作成
- ロールを作成
- 作成したロールにAWSマネージドポリシーをアタッチ
- 波田野さんが用意して下さったCloudFormation（以下、CFn）のテンプレートをダウンロード
- CFnのテンプレートに対してバリデーションチェック
- CFnのスタックを作成
- Lambda関数を実行し、IAMロールが動作しているかを確認
- CloudWatch Logsのログイベントを取得(filterログイベントは最新日付順じゃない？ので注意)
- 最後は後始末を忘れずに！
おわり
今回の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
- 2021/5/29 にリリースされたフルマネージドサービス
- GiHubリポジトリ、もしくはECRのコンテナイメージから超お手軽にWeb Applicationデプロイに必要な環境を全て用意してくれる
- SSL化やロードバランシング、オートスケーリング、CI/CD設定なんかも勝手にやってくれる
メリット
- 他のマネージドサービスより超お手軽にフルマネージドな環境が用意出来る
- GitHubリポジトリからでもコンテナイメージからでもデプロイが可能
- CI/CD環境がオプションひとつで簡単に構築可能
- 自動でSSL化される
- logはCloudWatchに自動で連携
デメリット
- VPCに配置出来ないため、RDSに安全にアクセス出来ない
- 本記事執筆時点でDBを使いたい場合はDynamoDBを使うことになりそう
- 料金が少しお高い
- これはフルマネージドなサービスなので仕方ない。。。
- 実際の使用用途があまり思い浮かばない
ハンズオン
それでは本題. 資料も充実してますので、是非やってみて下さい。
事前準備
以下のものを作業前に準備して下さい。
資料
今回は亀田さんがご用意して下さった資料をもとに進めました。
やってみた所感
- 自分はオレゴンリージョンで実施
- たくさんの人が同時に実施するのでリージョンを分散させた
- なんかgithubに接続出来ない。。ぐるぐる回り続けてる。。。と思ったら、CLI系の権限しか無いユーザーでログインしてた
- ルートユーザーで実施
- 本当にお手軽にデプロイ出来た
- 今回デプロイしたものは Hello World!（めちゃくちゃ殺風景な画像を載せてしまった。。。）
- 今回デプロイしたものは Hello World!（めちゃくちゃ殺風景な画像を載せてしまった。。。）
- ECRにコンテナイメージをデプロイする際に使うCloud9のインスタンスはt3smallを使おう
その他
- Cloud Formationのエラーを見るときは「イベント」タブを見る
- コンテナを実際に運用する場合には、コンテナイメージのtagをgitのコミットIDにするとトレースが楽
やってみたLT
3名の有志の方がLTを行なって下さいました。
AWS App Runner + copilot cli
Speaker : 小木悠斗さん（ yuto (@jacoyutorius) | Twitter ）
こんなお話
- 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専門支部です。）
事前に準備したもの
成果
内容
「EC2ハンズオン」
speaker: 波田野さん
- Amazon EC2とは？
Amazon Elastic Compute Cloud (Amazon EC2) は、アマゾン ウェブ サービス (AWS) クラウドでスケーラブルなコンピューティングキャパシティーを提供します。Amazon EC2 の使用により、ハードウェアに事前投資する必要がなくなり、アプリケーションをより速く開発およびデプロイできます。
Amazon EC2 とは - Amazon Elastic Compute Cloud
ハンズオン実施
- デフォルトVPCの構築*1
- ユーザーデータの作成
- EC2インスタンスの起動
- セキュリティグループへIngressルールを追加
- 起動したインスタンスへのアクセス
- インスタンスのパブリックIPにアクセスすると、コンテンツが表示された！
- インスタンスのパブリックIPにアクセスすると、コンテンツが表示された！
まとめ
VPC等のネットワーク関連のコマンドもEC2のAPIに含まれている、というのが意外でした。 独学でやろうとすると必ず躓いてたな。。。と思いましたねw この知識を得られただけでも、今回のCLI専門支部に参加した価値は十分にあったと思います。 CLIでのEC2インスタンス作成は初めてでしたが、ハンズオンの内容はそこまで複雑ではありませんでした。 波多野さんの素晴らしい資料を参考に、皆さんも是非ハンズオンやってみて下さいね。
