2025/03　技術インプットまとめ

日報




エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。

2025-3-3

MySQLのトリガー定義にて、LEAVEの挙動について知ることができました

  • LEAVEは、そのラベル（下記でいうafter_message_thread_insert_trigger）で囲まれた処理ブロックを抜けるという意味
  • トリガーは基本的に1つのBEGIN〜ENDで構成され、そこにラベルを付けることで、LEAVEが「ブロックの残りの処理をスキップする」ことを示す

CREATE TRIGGER after_table_insert
AFTER INSERT ON table
FOR EACH ROW
after_table_insert_trigger: BEGIN
  IF
    (条件) THEN
    LEAVE after_table_insert_trigger;
  END IF;
  — 以下は実行されない
  UPDATE table SET
  # クエリの続き
END
//
DELIMITER ;

2025-3-4

下記記事で言及されていることについて知ることができました。
https://ymmt.hatenablog.com/entry/2024/10/02/222243

2025-3-5

GitHub Actions の Artifactについて知ることができました

  • Artifactsとは、GitHub Actionsのワークフローの実行結果として生成されたファイルをアップロードし、後からダウンロードできる仕組み
  • Actions実行結果画面（Actionsタブ → 該当のWorkflow run）を開くと、右側や下部に「Artifacts」というセクションが表示される
  • そこに、アップロードされたファイル（例: coverage.out, ビルド成果物など）が一覧として並び、ブラウザからダウンロードできる
  • デフォルトでは保存期間があり、それを過ぎると自動的に削除される
  • この「Artifacts」に保存することで、CIの結果として出力されたファイルをチーム全員が参照できるようになる。一般的な使い方としては、テストレポートやカバレッジレポートを後からダウンロードして確認したり、バイナリをビルドしてデプロイ時に利用するなどがある。

GitHub Actionsで作った成果物を一時保管する仕組み。単なるログや実行履歴よりも幅広く、任意のファイルをアップロード・保存できるスペース

2025-3-6

GitHub Actionsにおける env のスコープについて知ることができました。

（GitHub Actions ワークフロー定義ファイル）
jobs:
  test:
    runs-on: ubuntu-latest
    env:
      ENV: ci
    steps:
      – name: Run tests
        run: go test ./…
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}

上記ワークフローの場合、jobs..env セクションに書かれた環境変数は、そのジョブ全体の実行期間中すべてのステップで有効になる。一方で、API_TOKENという環境変数は、そのステップ内だけ有効となり、次のステップでは利用できない。特定のステップだけに適用させたい環境変数がある場合は、ステップ定義のなかで env: を指定する。

2025-3-10

GitHub Tokenについて知ることができました。

GitHub Actions を実行する際、GitHub が自動で GITHUB_TOKEN（よく ${{ github.token }} と書く）と呼ばれるトークンを発行し、ワークフロー内で利用できるようにしてくれる。

この GITHUB_TOKEN は、リポジトリに対して一定の権限（読み書き権限など） を持ち、以下のような用途で使われる。

・PR（プルリクエスト）へのコメント投稿
・リリースやコミットステータスの更新
・IssueやPull Requestのラベル変更、マージ

プライベートで、CIワークフローにreviewdogを使ったコードの静的解析ステップを導入しました。そして、reviewdogによる静的解析にて、errorレベルの問題があれば、それをPRの該当行にコメントを入れてもらうよう設定しましたが、その際にGitHub Tokenが必要でした。GITHUB_TOKEN を使えば、わざわざ個人のPersonal Access Tokenを管理しなくても GitHub Actions 上で安全にリポジトリにアクセスできることを知りました。

2025-3-11

GitHub Actions上で actions/checkout@v4 を使用してリポジトリをCI環境にチェックアウト（クローン）する際に、fetch-depthを用いることで「取得するコミットの履歴の深さ」を制御することができることを知りました。そして、今回は fetch-depth: 0 と設定した際の挙動や、その設定を用いる意味について知見を得たため、それに関するアウトプットです。

前提として、actions/checkout@v4 を使用する場合、デフォルトでは最新コミットのみを取得するようになっている。しかし、fetch-depth: 0 と指定すると「リポジトリのすべてのコミット履歴を取得する」という意味になる。

fetch-depth: 0 を使うべき場面

  • コミット履歴を遡って解析する必要がある場合：例えば、差分比較や ChangeLog 生成など、過去のコミット情報が必要なケースで使われる
  • サブモジュールや Git のタグ、ブランチ操作が必要な場合：全履歴が必要になる可能性があるときに使われる

逆に「特定のコミットしか必要としない」場合には、デフォルトの fetch-depth（1など）で問題ない。fetch-depth: 0 を指定する場合、リポジトリ全体（すべてのコミット）を取得してくるため、その分ネットワークと時間コストが若干増えるというデメリットがある。

2025-3-12

変数のシャドウイング（variable shadowing）について知ることができました。

変数のシャドウイングとは、外側のスコープ（関数スコープやブロックスコープなど）で宣言された変数と同じ名前の変数を、内側のスコープで再宣言してしまうことにより、外側の変数が「隠される」（shadow = 影になる）状態を指す（下記一例）

var foo = 10
func main() {
  foo := 20
  println(foo) // 20
}

上記コードでは、main関数の外側スコープで foo が宣言されているが、main関数の内側でも foo := 20 と書くことで同名変数を新規宣言している。これにより、外側の foo (10) は見えなくなり（隠され）、内側で宣言した foo (20) が優先して使われる。これを変数のシャドウイングという。

シャドウイングは、コード可読性の低下や、意図しない振る舞いにつながる場合があり、バグの原因になりやすい。そのため、シャドウイングを検知する静的解析ツールも存在する。

2025-3-12

PHPを含む多くの言語実装で利用されているコピーオンライト (Copy On Write) という最適化手法について知ることができました。

コピーオンライトとは、プログラムが同一データを複数の変数や参照で共有しているとき、実際にデータが変更される（書き換えが必要になる）タイミングまで物理的なコピーを作らない, 行わない仕組み, 最適化手法のこと。

例えば、PHPの配列の場合、下記のようなコードがあったとして

$a = [1, 2, 3];
$b = $a;

この時点では、PHPは配列 [1, 2, 3] をまるごと物理コピーしない。実際には「同じデータ領域を共有し、参照カウンタを増やす」だけで済ませる。

$b[0] = 100;

ここで、$b（あるいは$a）を書き換える必要が生じた時点で、PHPは初めて物理的なコピーを行い、$b用の新しい配列を作って書き換えを適用する、という挙動をとる。これによって、無駄に大きなデータ構造をコピーするコストを削減できる仕組み。

2025-3-13 ①

Amazon SQS において、２種類のキューが存在することを知りました。

1, Standard Queue (標準キュー)

  • 高スループット、順序はベストエフォート（ほぼ順番通りだが、順不同になる可能性がある）
  • 同じメッセージが重複して配信される場合もある
  • 多くのユースケースで最も一般的に使われる

2, FIFO Queue (FIFOキュー)

  • メッセージの厳密な順序（FIFOを保証）
  • 重複排除機能（Exactly-Once Processing）もあり、1回の送信でメッセージが重複して配信されないようにできる
  • 1秒あたりのトランザクション数（TPS）に上限（標準より低い制限）があるなど、運用上の注意点もある

キューサービスである以上、自然とFIFOは守られているのかなと思いましたが、厳密にFIFOを保証したい場合は明示的にFIFOキューを利用する必要があり、多くのユースケースでは「ほぼ順番通りだが、順不同になる可能性があるStandard Queue」が用いられることを知りました。

2025-3-13 ②

OSファイルシステムがデフォルトで大文字・小文字を区別しない挙動により、gitがその影響を受けて、例えばApi.phpとAPI.phpを同じファイルとみなし、renameしても差分として認識してくれないケースがあることを知りました。

  • Gitは、OSのファイルシステムが大文字,小文字を区別するかどうかを自動的に検知し、core.ignorecaseという設定を決める
  • WindowsやmacOS上では、既定でcore.ignorecaseがtrueになっており、大文字,小文字だけの変更を無視する挙動になる
2025-3-14 ①

Amazon SQSに関して、なんとなく「SNS から受け取ったメッセージのみ格納可能なキューサービス」というイメージでしたが、あらゆるAWSサービスや外部システムからのメッセージを受け取れる汎用的なキューサービスであることを知りました。

SNS → SQS連携（サブスクリプションの一種）はよく使われるパターンの1つ
・例：SNSトピックに Publish すると、その購読先が SQS キューで、すぐにメッセージがキューに入る
・そこからコンシューマが定期的に SQS をポーリングし、メッセージを取り出す

しかし、SQSに対して、任意のプロデューサーから直接APIを呼んでメッセージを送信できる
・SNS以外でも、Lambda, EC2, ECS, アプリケーション、オンプレミスのプログラムなど
・SDK / CLI / API経由で SendMessage を呼べば、どこからでも SQS に送信可能

2025-3-14 ②

サブネット CIDR が /24 の場合の IP アドレス割り当てについて、ホスト部が0と255は使用できず、それ以外の254個のIPアドレスは利用できると思い込んでいましたが、実はそうではないことを知りました。

AWS VPC では、下記 5 つのアドレスは予約されており、使用できない
10.10.1.0（ネットワークアドレス）
10.10.1.1（VPC ルーターで使用）
10.10.1.2（DNS 等で使用）
10.10.1.3（将来の用途等で予約）
10.10.1.255（ブロードキャストアドレス）

結果として、10.10.1.4〜 10.10.1.254 の 251 個のアドレスが、実際にリソース（ENI）に割り当て可能な IP となる

2025-3-18

CloudFormationのOutputsセクションの用途と使用することによるメリットを知ることができました。

CloudFormationのOutputsセクションは、スタック内で作られたリソースのIDやARN, URLなど後で外部から参照したい情報をまとめて「スタックの出力」として定義しておくための機能

（主な用途）
1、スタックデプロイ後に「すぐ確認したい情報」を見やすくする

例えば、S3バケット名やELBのDNS名, API Gatewayのエンドポイント, RDSのエンドポイントなど。CloudFormationスタックを作成した直後、マネジメントコンソールの「スタックの出力タブ」やCLIのdescribe-stacksコマンドで、これらの情報を簡単に確認できるようにしたいときに便利。運用手順書やCI/CDパイプラインの出力ログで、スタックのOutputsを参照すれば、必要なIDやエンドポイントを探す手間が減るメリットがある。

2、他のスタック（または手動作業）で利用するパラメータを分かりやすくまとめる

Outputsで定義された情報は、Export機能を使うことで、別のスタックから簡単に !ImportValue で参照できる。「あるスタックでVPCやSubnetsを作り、別のスタックでそれらを利用したい」という構成の場合、VPC IDやSubnet IDをOutputsにまとめてExportしておくと、下流のスタックにて !ImportValue で簡単に受け取れる。

3、AWS外部の設定や通知先として活用

例：ChatOpsなどで「CloudFormationスタックが出来上がった後、このOutputsに書かれているエンドポイントをSlackに通知する」、「TerraformやPulumiのような別ツールからこの値を取得して別の設定を行う」など。要は「CloudFormationで生成したリソース情報を外部システムに連携しやすくするための仕組み」として使われる。

（メリット）
・スタックで生成した重要な情報（ID, ARN, エンドポイントなど）を一括で見られる
・他のスタックや外部ツールがその情報を参照する際に使いやすい

2025-3-18

CloudFormationマクロについて知ることができました

1、マクロ（template macros）の概要

マクロは、CloudFormationテンプレートをデプロイする前に、ユーザー定義の変換処理を行う仕組み。テンプレート中に Transform: キーを使ってマクロを指定し、CloudFormationはマクロを呼び出して、テンプレートの構文やリソース定義を動的に変換する。変換後のテンプレートが最終的に CloudFormation スタックとして適用される。

2、公式マクロとカスタムマクロ

公式マクロ：例えば Transform: AWS::Serverless-2016-10-31 は、AWS が提供するSAM（サーバーレスアプリケーションモデル）のマクロ。他にも AWS::Include transform があり、外部ファイルを取り込むといった機能も公式提供されている

カスタムマクロ：Lambda 関数で独自のマクロ処理を作ることも可能。たとえば、テンプレート内の繰り返し処理を自動展開したり、ユーティリティ的な置換を行ったりといった柔軟な変換ができる

3、CAPABILITY_AUTO_EXPAND

マクロが含まれているテンプレートをデプロイする際には、–capabilities CAPABILITY_AUTO_EXPAND を付与する必要がある。こうすることで CloudFormation がマクロを自動的に展開してよい と承認する形になる。

2025-3-24

VPCフローログについて知ることができました。

  • VPCフローログとは、VPC内のネットワークインターフェイスを通過するトラフィック情報をキャプチャして、Amazon CloudWatch LogsやAmazon S3に記録できる機能
  • 通信ログを取得して分析したり、セキュリティ上の監査を行いたい場合に非常に有用な仕組みとなっている
  • 対象：VPC、サブネット、または個別のENI
  • 記録先：Amazon CloudWatch LogsまたはAmazon S3
  • トラフィックタイプ：ACCEPT, REJECT, ALL などを選択可能（例えば、Inbound/Outbound問わず許可・拒否された通信を含めてすべて取得したい場合は ALL）
  • フローログが記録してくれる情報には、通信元/通信先IPアドレス、ポート番号、プロトコル、パケット数、バイト数、通信の許可/拒否のステータスなどが含まれる

フローログを使用すべき場面

1. セキュリティ・監査目的：どの通信がVPC内で許可あるいは拒否されたかを把握し、侵入の痕跡や想定外の通信を調査・監査したい場合

2. トラブルシュート・ネットワーク解析：通信が届かないときや思わぬ経路で通信が行われている疑いがあるときにフローログを使うと、どこでブロックされているのかや、どのIPアドレスから通信が来ているかなどを詳細に分析可能

3. 可観測性（Observability）向上：CloudWatch LogsやS3などに蓄積しておくことで、将来の問題発生時に遡ってトラフィックパターンを調査したり、アラート条件を設定して自動通知を実装するなど、システム可観測性の向上につながる

基本的には、本番環境のVPCなどセキュリティ上センシティブな環境ではフローログを有効化することが推奨される。ただしフローログを保存し続ける分のコスト（CloudWatch LogsやS3の保存費用等）がかかるため、必要に応じて取得対象・期間・サンプリングを検討することが多い。

2025-3-25 ①

AWS cloudformationにて、Type: AWS::Scheduler::ScheduleGroup がどういったリソースを定義するためのタイプなのか知ることができました。

  • AWS::Scheduler::ScheduleGroup は、Amazon EventBridge Scheduler のスケジュールグループ（Schedule Group）を作成, 管理するための CloudFormation リソースタイプ
  • Amazon EventBridge Scheduler では、定期実行したいジョブ（スケジュール）をまとめて管理する機能として「スケジュールグループ」という概念がある
  • スケジュールグループを使うことで、関連するスケジュール同士を論理的にグルーピングできるほか、一括での管理や設定がしやすくなる

CloudFormation で AWS::Scheduler::ScheduleGroup を定義すると、以下のようなことが可能になる

  • スケジュールのグループ化：関連するスケジュールをまとめて管理するためのグループを作成
  • アクセス制御やタグ付けの単位：スケジュールごとではなく、グループ単位で IAM ポリシーやタグを適用したり、管理することができる
  • ライフサイクル管理：不要になったスケジュールグループを削除すると、そのグループに属するスケジュールもまとめて削除できるなど、一括管理が行いやすくなる

具体的には、CloudFormation テンプレート内で以下のように記述するイメージ
Resources:
  MyScheduleGroup:
    Type: AWS::Scheduler::ScheduleGroup
    Properties:
      Name: “my-schedule-group”

上記のような定義をすることで、Amazon EventBridge Scheduler 上に「my-schedule-group」というスケジュールグループが作成される。あとは AWS::Scheduler::Schedule リソースを作成するときに、そのスケジュールがどのスケジュールグループに属するか指定することで、グルーピングが可能になる。

2025-3-25 ②

AWS cloudformationにて、Type: “AWS::Scheduler::Schedule”を用いたリソース定義で設定可能なFlexibleTimeWindowプロパティがどういった設定項目か理解することができました。

  • 「柔軟な実行ウィンドウ」を設定するためのプロパティ
  • 通常、スケジュールは指定した時刻に厳密に実行されるが、FlexibleTimeWindow を有効にすると、ある程度時間の余裕を持たせて実行タイミングをずらすことが可能
  • 一度に多数のスケジュールジョブが重なるときに、同時実行による負荷を緩和するため、ある程度分散して実行するなどの制御に使われる
  • 設定可能なプロパティ1 Mode：OFF または FLEXIBLE
  • 設定可能なプロパティ2 MaximumWindowInMinutes：任意、Mode が FLEXIBLE の場合に指定

設定例（yaml）
FlexibleTimeWindow:
  Mode: FLEXIBLE
  MaximumWindowInMinutes: 15

この例では、スケジュールで指定された時刻がきた後、最大15分の間に実行タイミングをずらすことが許可される。一方、Mode: OFF を指定すれば、指定した時刻ぴったりに実行される（柔軟性を持たせない）という設定になる。

2025-3-26 ①

GitHub ActionsからOIDCを利用してAWSにインフラリソースをデプロイする際の全体的な流れを知ることができました。

大まかに以下のステップで、GitHub Actions は AWS 側のロールを “AssumeRole” してリソースにアクセスできるようになる

1. GitHub Actions が実行される
2. GitHub Actions のジョブ内で 「GitHub の OIDC プロバイダー」 を使い、一時的に発行された “OIDC トークン (JWT)” を取得
3. AWS 側（IAM）の Identity Provider と IAM ロールの信頼ポリシー (Trust Policy) が、この GitHub から発行されたトークンを検証・認可
4. 検証が成功すると、AWS STS から一時的なクレデンシャル（セッショントークン付きのアクセスキー）が払い出される
5. GitHub Actions は払い出された一時クレデンシャルを使って、aws cli や aws cloudformation deploy コマンドを実行 → AWS リソースを操作

これにより、GitHub レポジトリやブランチなど特定の条件を満たしたジョブのみ AWS リソースにアクセス可能となる

2025-3-26 ②

LBなしでECSタスク間通信を実現する方法の１つとして、AWS Cloud Map（ECSサービスディスカバリ）を使う方法を知りました。

  • ECSサービスにCloud Mapを設定すると、タスクのIPアドレスがDNSに登録される
  • タスクAが service-b.local のようなFQDNを使って、タスクBにアクセスできる
  • SRVレコードを使えば、負荷分散も可能（ただしALBほど高機能ではない）
  • ただし、タスクのスケール時にDNSキャッシュの問題が発生する可能性があるため、TTL設定に注意が必要

Cloud Map を使った通信の流れ
1. サービスAのタスク が サービスBのタスク にリクエストを送信（http://service-b.local:8080 など）
2. Cloud Map の DNS レコードを参照して、サービスBのタスクIPを解決
3. 直接 Fargate のタスクIP にリクエストを送信し、レスポンスを受け取る

→ Cloud Map を使えばLBを介さずに通信可能だが、ALBを使うより運用が少し難しくなる

2025-3-28

GitHub Actionsにて、workflow_run というイベントを使うことで、特定のワークフロー（Workflow A）が完了したら（成功したら）Workflow B を起動する、といった形を作れることを知りました。

ただし、設定や管理がやや煩雑になるため、規模が大きくない場合は「1つのワークフロー内でジョブを分割し、needs で依存を明示」する方法のほうがシンプルなことも多い

2025-3-31

AWS IP Address Manager（IPAM）について理解することができました。

AWS IP Address Manager（IPAM）とは、企業や組織が管理する多くの VPC/サブネット/オンプレネットワークの IPアドレス割り当てを一元的に管理・追跡するためのサービス

主な機能
1. 一元管理：マルチアカウント、マルチリージョンにまたがるIPアドレス空間を集中管理できる

2. アドレスプールの割り当て：VPC やサブネットを作成する時に、IPAM に定義した「プールID」からサブネットマスク長を指定して自動でCIDRを割り当てられる

3. 重複回避：アドレスが重複しないように自動チェックし、管理をシンプルにする

4. 監査・可視化：どのネットワークリソースがどのIP範囲を使っているか可視化できる

単一アカウント、単一VPCレベルの管理で IP衝突のリスクが低い、小規模な構成であれば IPAM はなくても問題ない

大規模環境、マルチアカウント/複数リージョンで IP管理の手間が増えたときに導入することが多い