aws・Github Actions

 目次
[] ecs・AIMロール
[] VPC基本(ネットワーク)
[] lamnda
SQS
[] https://zenn.dev/voicy/articles/a09a6ac171f82e

[] teraform
[] rds
[] s3
ALB
sns
[] event bridge
batch

[] SNS

 cloud watch・メモリ
github actions
まとめる
https://www.notion.so/Github-Actions-kindle-19ba85acf33543658a17277b7a9db420

まとめる
https://www.notion.so/cloud-tech-1db031b7ac3d8085a344e4339895a79a



 用語
エージェント
特定のタスクや監視を自動的に行う常駐プログラム

engineer reborn

 ecs

 IAMロール
信頼側とアクション側がある
構造
ロール
ポリシー
IAMロール
信頼側のポリシー
誰がこのロールを引き受けるか？を決めるもの
作業
ロール作成
ユースケース
Ec2が引き受けることを決める





アクション側(ec2側)
このロールを使って、どのリソースが何をしていいか
これが一般的なポリリー
CloudWatchAgentServerPolicy
https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/CloudWatchAgentServerPolicy.html
cloud watchへの書き込みとかの権限がある

engineer reborn

 ssm AWS Systems Manager
運用管理サービス
ソフトウェア情報の収集
ec2、オンプレの管理


 ステップ
NWの設定
IAMRole
SSM Agentの導入
常駐ソフトウェア



 機能のカテゴリ
運用管理
アプリケーション管理
変更管理
ノード管理
⭐️セッションマネージャ
プライベートサブネットに接続する時に便利
Bastionサーバーを挟む必要がある
ブラウザでアクセスできる！
SSM Agent経由でアクセス



⭐️Run Command
コマンドをブラウザから実行できる

パッケージマネージャー

共有リソース


 セッションマネージャー
テスト環境
private subnet
vpcから一括で作成

ecs


 vpcエンドポイント

作業
vpcからネットークを一括で作成
パブリックサブネットは0
vpcエンドポイントはs3ゲートウェイはなし
DNSオプションはチェック

engineer reborn

 cloud watchcloud watchの構成要素
ロググループ
フォルダみたいなもの

ログストリーム
ファイルみたいなもの
インスタンス・コンテナごとに作成
コンテナで再起動するとコンテナIDが変わるので都度できるみたい
APIのコンテナデプロイ
デプロイごとにコンテナIDが新しくなるのでストリームも新しくなる

バッチの実行の場合は実行の時に都度コンテナが立ち上がるのでストリームができる
そのバッチ単位のログがそのストリーム内で、LogEventとして記録される





LogEvent
1行1行のログデータ


Log Group (例: /aws/ec2/your-app)
│
├── Log Stream (例: i-0abcd1234)
│    ├── Log Event (例: "2025-07-05 10:00:00 アプリ起動しました")
│    ├── Log Event (例: "2025-07-05 10:01:00 エラーが発生しました")
│    └── ...
│
├── Log Stream (例: i-0efgh5678)
│    ├── Log Event
│    └── ...
│
└── ...

⭐️ログを記録するわけではない
ec2のメトリクスの確認のため!!
検証環境
パブリックサブネット
ec2
インターネットゲートウェイを経由して
cloud watch
設定ファイル
作業
vpc作成
パブリックサブネット1つ
IAMロール
信頼側のポリシー
誰がこのロールを引き受けるか？を決めるもの
作業
ロール作成
ユースケース
Ec2が引き受けることを決める



アクション側(ec2側)
このロールを使って、どのリソースが何をしていいか
これが一般的なポリリー

CloudWatchAgentServerPolicy
https://docs.aws.amazon.com/ja_jp/aws-managed-policy/latest/reference/CloudWatchAgentServerPolicy.html
cloud watchへの書き込みとかの権限がある


ec2
ssh接続できるようにkeyペアで
上記で作成したIAMロールを設定
CWAgent(cloud watch agentの略)
ssh接続
cloudwatch agent入れる(常駐ソフトウェア)
sudo yum install -y amazon-cloudwatch-agent

config-wizardでconfigを設定する
os
linux

use
root

statsd
no

cllectd
no

monitor cpu
yes

ec2 dimension
cloud watch Log Agent
昔使っていた人向け
no

⭐️ロググループの指定
collect_listの項目設定
ファイルの収集先指定
file_path

log_stream_name
{instance_id} など変数を使える

ロググループ名指定
log_group_name




起動コマンド実行
13:50あたり

CWAgent(cloud watch agentの略)
instakIDで検索できる
mem


 container insight
パフォーマンスを観察できるもの

 構造クラスター
タスク
これらの単位でCPUやメモリ、ネットワークがわかる

 メモリ
 データだけビット
1bit

バイト
8ビットが1バイト

文字レベルの単位
1バイト
アルファベット1文字ほどに使われる

2バイト以上
日本語



キロバイト(KB)
1024バイト

テキストや文字列のレベル
1KB
短いテキスト数百文字
メールの本文だけ



メガバイト(MB)
1024キロバイト

WordやPDF
1MBは数百ページの文章ファイル(word PDF)


ギガバイト(GB)
1024メガバイト

写真や音楽ファイルレベル
数百、数千枚の写真や数時間の音声ファイル


テラバイト(TB)
1024ギガバイト
動画レベル



 APIやバッチ変数への格納・キャッシュ(プログラマがやりがち)
変数
DBから大量のデータを一度に読み込んで、メモリスライスに乗せすぎる

キャッシュ
乗せすぎ

パッケージ・バッファ
grpcのパッケージアップデートでメモリ増加
バッファの悪化らしい
データの溜め込める箱
ネットワーク通信、ファイル読み書きなどで、一気にデータを送れない／受け取れない ときに、一旦バッファに貯める。
buf := make([]byte, 1024) // 1KBのバッファ
n, err := conn.Read(buf)

go routineやスレッド
データベースの接続

 実務でやるケース前提
1コンテナに 512MB メモリ制限
イメージ
Userの構造体だと、ざっくり1レコードが 52B
type User struct {
    ID    int64  // 8 bytes
    Name  string // ヒープ領域の参照（string ヘッダ 16 bytes + 実際の文字列データ）
    Age   int    // 8 bytes (int64想定の場合)
}
536,870,912 ÷ 52 ≈ 10,324,440 件(1000万件)
オーバーヘッド
70〜80% くらいの効率
つまり理論値より下回るってことかな
おおよそ、7〜8百万件のデータ量である


コンテナ数
分割設計する必要がある
理由は、1000件の処理でバッチのメモリが足りなくなってしまう場合、シンプルに落ちて再実行になる
対応としては分割実行をする必要がある
# コンテナA
./your-batch-binary --user-id-mod=0 --divisor=3

# コンテナB
./your-batch-binary --user-id-mod=1 --divisor=3

# コンテナC
./your-batch-binary --user-id-mod=2 --divisor=3

engineer reborn

 EventBridge
※以前はcloud watch Eventだったらしい
サーバーレスのイベントバス型サービス
バスとは
通信路



 構造
イベントソース
ターゲット
イベント
イベントバス
ルール


 Eventとは
ec2
実行中から終了する時に、状態のイベントが発生する



 イベントバズの種類
イベント
AWSサービスのイベント
カスタムアプリケーションののイベント
SasSアプリケーションのイベント

バス
デフォルトイベントバス
カスタムイベントバス
ASassイベントバス



 実際の例
ec2が終了 => Event発生
デフォルトバス
ルールで処理
条件の設定
ターゲットを選択(SNSを指定)

SNSでメールを送る


 定期実行
event bridge
cron式 rate式

lambda
rdb


 入力トランスフォーム
イベントの情報をsnsなどに渡すことができる

engineer reborn

 SQS

 前提
楚結合(デカップリング)でない設計


 楚結合設計
2台のec2の間にSQSを入れる
キュート・メッセージ
構成
プロデューサー
メッセージを送る

SQSにキューを貯める
コンシューマー
ポーリングしてメッセージを受け取る




 キューの種類
スタンダート vs FIFOキュー


 デッドレターキュー
キューの連携が失敗すると、DLQ(デットレターキュー)に貯められる
cloud watchで通知を飛ばすのもできる



 遅延キュー

 ショートポーリング・ロングポーリング
ショートポーリング
コンシューマーが要求と受信をする
データがなけれは空のデータを返す => 無駄なポーリングが増えるので、ロングポーリングを使うことが多い


ロングポーリング
コンシューマーが要求してから待機して受信



 ハンズオン
SQSとLamnda
テスト
マネジメントコントロール => メッセージ => キュー => lambda
実践的⭐️「キューに対するポーリング」と「メッセージの削除」を通常行うが、lambdaは自動で
ポーリングをするケースは少ないのかも、lambdaを挟むことが多そうだし


作業
キューを作成
標準キュー

lambda関数の作成
ランタイム Python
アクセス権限
ロールを設定
ポリシーをsqsのポーリングアクセスを設定


トリガー設定
指定したキューを設定する

関数を作成
ログ出しの関数


メッセージの送信
マネジメントコンソール。GUIの画面でメッセージの送受信ができる


DLQ作業
キューの作成
最初のキューの編集
デットレターキューを有効にする
デットレターキューを設定

lamdaのコード編集
偶数奇数でエラーを投げるらしい⭐️ キューの連携先の関数でエラーを発生したら、DLQに入る！！
エラーを発生させると、デットレターキューにキューが格納されてている


DLQをマネジメントコントロールで再実行して、lamdaを再実行(関数は正常にしてる)

engineer reborn

 SNS(Simple Notification Service) プッシュ型(SQSはプル型)
Puhliser/Subscriber
Puhliser
SNSに向かって情報を飛ばす
SQSと
ec2インスタンス
EventBridge


Subscriber
Lambda
SQS
emailなど



 Pub/Subメッセージングモデル
送信者は特定の受信者を想定しないでメッセージを送る
送信者・受信者が互いにそれぞれの知識を持たない


 利用例
cloud watchのアラート => SNS => lambda => slackなど
s3 => SNS => SQS => ec2
ファンアウト設計

engineer reborn

 ALB

 PATHベースルーティング
メリット
わかりやすい
cookieを共有できる
ex)

https://hoge.jp
本体のフロント


https://hoge.jp/blog
wordpressのコンテナ






 サブドメとALBで冗長化
example.comのドメインを取得
route 53(サブドメをきるところまで)
example.comをフロント用に
api.example.comをサブドメでバックエンド用に

ALBでそれぞれ紐付けることで冗長化を実現
example.comをフロントのコンテナ
api.example.comをバックエンドのコンテナ