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

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

2025-6-2

下記が何をやっているのか知ることができました。

/etc/php.ini
memory_limit = -1

上記では、PHPスクリプトが使用できるメモリの上限を無制限にしている。

通常、PHPスクリプトが使用できるメモリの量には上限が設定されている。これは、特定のスクリプトがサーバーのメモリを使い果たしてシステム全体に影響を与えるのを防ぐため。 memory_limit = -1 と設定すると、この上限が取り払われ、PHPスクリプトは理論上、サーバーが利用可能なすべてのメモリを使用できるようになる。

この設定は、非常に大きなデータを処理する必要がある場合など、特定の状況では役立つことがある。しかし、以下の点に注意が必要
・サーバーリソースの枯渇：スクリプトにバグがあったり、予期せぬ大量のデータを処理しようとしたりした場合、サーバーのメモリをすべて消費し、他のプロセスやシステム全体の動作に深刻な影響を与える可能性がある。最悪の場合、サーバーがクラッシュすることもある。
・パフォーマンスの問題：大量のメモリを消費するスクリプトは、一般的にパフォーマンスが低下する傾向がある

推奨事項としては、本当に必要な場合を除き、メモリ上限を無制限に設定することは避けるべき。スクリプトが必要とするメモリ量を正確に見積もり、適切な値を設定することが望ましい。

2025-6-3

DNSサービス全体に存在する標準的なレコードタイプであるTXTレコードについて、どういったレコードか知ることができました。

・TXTレコードとは、ドメインに関するテキスト情報を格納するためにDNSで使用されるリソースレコードの一種
・このテキスト情報には、人間が読める形式のメモや、機械が解釈するためのデータなど、様々な情報を記述できる

TXTレコードの主な用途

1. ドメイン所有権の確認
・Google Search ConsoleやMicrosoft Azureなどのサービスで、自分がドメインの所有者であることを証明するために利用される
・サービス提供者から指定された特定の文字列をTXTレコードに設定することで認証を行う

2. メール送信ドメイン認証
・SPF：送信元メールサーバーのIPアドレスを記述し、正当なサーバーから送信されたメールであることを示すために利用される。これにより、なりすましメールを防ぐ効果がある
・DKIM：電子署名を利用してメールの送信元ドメインの正当性とメール内容の改ざんがないことを証明するために利用される。公開鍵の一部をTXTレコードに記述する
・DMARC：SPFとDKIMの認証結果に基づいて、受信側サーバーがメールをどのように処理すべきか（例：そのまま受信、迷惑メールフォルダへ、受信拒否）を指示するポリシーを記述する

3. その他サービスでの利用：特定のアプリケーションやサービスがドメインに関する追加情報を必要とする場合に利用されることがある

TXTレコードの特徴
・任意の文字列：基本的に任意のテキスト文字列を値として設定できるが、多くの場合、特定のフォーマットや内容がサービス提供者から指定される

・複数の値：1つのドメイン名に対して複数のTXTレコードを設定することも可能。ただし、SPFレコードのように1つのドメイン名に対して1つしか設定できないとされているものもある（厳密には複数の文字列を1つのTXTレコードに含めることで対応する）

・長さ制限：TXTレコードに設定できる文字列の長さには制限がある。例えばRoute53の場合、1つの文字列は最大255文字で、1つのレコードに複数の文字列を含めることができるが、レコード全体としても実質的な上限がある

まとめ
・Route53のTXTレコードは、ドメインに関する様々なテキスト情報を格納するための重要なDNSレコード
・特にドメイン認証やメールセキュリティの向上に不可欠な役割を果たしている

2025-6-4

ターゲットとなるリソースが存在しない状況で、ALB, リスナー, ターゲットグループを先行してデプロイしても問題ないことを知りました。ターゲットが存在しないことによるヘルスチェック失敗を懸念していましたが、それは起こらず、むしろ今回ターゲットとなるECSタスク（それに合わせてECSサービスも）を先にデプロイしたら、登録先ターゲットグループがLBに紐づいていないというエラーでデプロイに失敗しました。

2025-6-5

RDS Aurora MySQLに関して、一部のインスタンスクラスではPerformance Insights機能がサポートされていないことを知りました。
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.Engines.html

2025-6-6

AWS Secrets Managerには削除待機期間が存在することを知りました。

・各シークレットには、削除待機期間が存在する
・削除待機期間は7〜３０日間で、ユーザーが指定可能
・削除待機期間中は「削除保留中」の状態となり、完全に削除されるまでは同じ名前で新しいシークレットを作成することができない

2025-6-9

RDSへの接続に関して、従来の固定パスワード方式に代わり、IAMを利用して動的に認証を行うことで、よりセキュアにRDSへ接続する方法を学びました。

IAM認証の基本的な考え方
DBホスト、ポート、DBユーザー名といった接続先の識別情報は、従来通り環境変数などでアプリケーションに設定する。最も大きな違いはパスワードの扱い。固定パスワードをコードや環境変数に保存するのではなく、アプリケーションの実行時にIAMロールの権限を使って、有効期限の短い（デフォルト15分）一時的な認証トークンを動的に生成する。この生成されたトークンをパスワードとして利用して、データベースに接続する。

IAM認証の主なメリット
・セキュリティの向上：静的なパスワード情報がどこにも存在しなくなるため、認証情報の漏洩リスクが根本から排除される
・認証管理の一元化：データベースへのアクセス権限をAWSのIAMで一元管理できるため、運用がシンプルかつ確実になる

実装に必要な設定ステップ（IAM認証を実現するためには、以下の4つの要素を設定する必要がある）
・RDSインスタンス側の設定：対象のDBインスタンスで「IAM DB認証」を有効にする

・IAM側の設定：rds-db:connect アクションを許可するIAMポリシーを作成する。作成したポリシーをアタッチしたIAMロールを作成し、アプリケーションにアタッチする（ECSタスクの場合、タスクロールとして指定）。

・データベース側の設定：IAM認証専用のDBユーザーを作成する（例： CREATE USER ‘user_name’ IDENTIFIED WITH AWSAuthenticationPlugin AS ‘RDS’; ）

・アプリケーション側の実装：AWS SDK（例: boto3）を使い、generate_db_auth_token APIを呼び出して認証トークンを取得するコードを実装する。取得したトークンをパスワードとしてDB接続ライブラリに渡す。SSL/TLSによる暗号化接続が必須となるため、接続設定で有効化する。

2025-6-10

AWS ALBのヘルスチェックにおいて、ヘルスチェックパスとして nginx が静的コンテンツを返すパスである /foo に設定したところ、200 を期待しているケースで 301 が返ってきてしまい、ヘルスチェックに失敗する事象に遭遇しました。なぜ 301 が返ってきたのか、nginxの挙動を知る機会となりました。

原因となったNginxの挙動
nginxは、リクエストされたパス（ /foo ）がサーバー上のディレクトリであると認識すると、URLの末尾にスラッシュを付けた正規の形（ /foo/ ）へ自動的にリダイレクトする。これは、その後のHTML内で読み込まれるCSSや画像などの相対パスを正しく解決させるための、nginxの標準的で重要な仕様。例えば、/foo/index.html 内でのような相対パスの画像読み込みがあった場合に、もしブラウザが /foo というURLのままこのHTMLを受け取ると、画像へのリクエストは /image.jpg となってしまい、意図した /foo/image.jpg にならない。最初に /foo/ へリダイレクトしておくことで、ブラウザは基準となるパスがディレクトリであることを正しく認識し、画像などのリソースを正しく /foo/image.jpg としてリクエストできるようになる。

上記の通り、nginx の挙動が原因であることを知りました。そのため、ALBのヘルスチェックパスを初めからスラッシュを付けた /foo/ に変更することで、nginx がリダイレクトを行わなくなり、200 を返してくれるため、ヘルスチェックが成功するようになりました

2025-6-11

CNAMEレコード（Canonical Name Record）について理解することができました

CNAMEレコードとは、あるドメイン名を別のドメイン名（正規名）に転送（エイリアス）するためのレコード

CNAMEレコードのポイント
・ドメイン名を別のドメイン名に対応付ける：IPアドレスに直接対応付けるわけではない
・サブドメインに利用可能： www.example.com や blog.example.com のようなサブドメインによく使われる
・基本的にはルートドメインには設定できない：example.com のようなルートドメイン（ネイキッドドメインとも呼ばれる）には、他のDNSレコード（SOAレコードやNSレコードなど）との競合を避けるため、CNAMEを設定できないというDNSの仕様上の制約がある（一部のDNSプロバイダでは独自機能で対応している場合もあるが、一般的ではない）

2025-6-12

Route53の独自機能であるエイリアスレコードについて理解することができました。

エイリアスレコードとは、Amazon Route53独自の機能で、CNAMEレコードと似ているが、より高機能。AWSリソース（ALB、CloudFrontディストリビューション、S3バケットなど）に対して、ドメイン名をマッピングする際に使われる。例えば、myapp.example.com というドメイン名に対して、特定のALBを指定するエイリアスレコードを設定した場合、ユーザーが myapp.example.com にアクセスすると、Route 53は内部的にALBの現在のIPアドレス（複数ある場合もある）を調べて応答する。見た目上は、AレコードやAAAAレコードのように振る舞う。

エイリアスレコードのポイント
・AWSリソースに特化：ALB、CloudFront、S3など、特定のAWSリソースを指し示すために設計されている
・ルートドメインにも設定可能：example.com のようなルートドメインにも問題なく設定可能（これが最大の利点に感じます）
・IPアドレスの動的変更に自動追従：指し示しているAWSリソースのIPアドレスが変更されても、Route53が自動的に追従してくれるため、レコードを更新する必要がない
・追加料金なし：エイリアスレコードのクエリは追加料金なしで利用可能（標準のDNSクエリ料金は発生する）
・CNAMEのような2段階の名前解決が不要：CNAMEレコードでは一度別のドメイン名を返してから再度IPアドレスを問い合わせるが、エイリアスレコードではRoute53が直接IPアドレスを返すため、若干だが名前解決のパフォーマンスが上がる

2025-6-13

GitHub Actionsで利用可能なMatrix Strategy（マトリックス戦略）について知ることができました。

Matrix Strategyとは、1つのジョブ定義から複数のバリエーションのジョブを自動的に生成して実行するための機能。ワークフローファイルにマトリックスを定義することで、異なるOS、プラットフォーム、プログラミング言語のバージョンなどを組み合わせて、テストやビルドを効率的に実行できる。

Matrix Strategyは、同じような手順を異なる環境で実行したい場合に非常に役立つ。
・複数のOSでテストしたいとき：Windows, macOS, Ubuntu など、複数のOSでアプリケーションが正しく動作するかを確認する
・複数の言語バージョンでテストしたいとき：Node.js 18, 20, 22 や Python 3.9, 3.10, 3.11 など、サポートする複数のバージョンでライブラリやアプリケーションの互換性をテストする
・複数のアーキテクチャでビルドしたいとき：x86_64 や ARM64 など、異なるCPUアーキテクチャ向けのビルドを生成する

2025-6-16

ロギングにて、__name__を使用してどのモジュールからのログかを識別するために利用される例を知ることができました

import logging
logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

上記コードの場合、logging.getLogger(__name__) とすることで、ログ出力元を特定しやすくなる。もしこのコードが含まれるファイルが、Lambdaのハンドラとして直接実行される場合、__name__ は “__main__” となり、ロガーの名前は “__main__” になる。もしこのコードが含まれるファイルが、別のPythonファイルからインポートされて実行される場合、__name__ はそのファイルのモジュール名（例：my_module.py なら “my_module”）となり、ロガーの名前もそのモジュール名になる。

2025-6-17

CloudFormationの AWS::ECS::TaskDefinition リソースで使用される EnableFaultInjection プロパティについて知ることができました。

このプロパティは、ECSタスクが AWS Systems Manager Experiment Manager を使用した障害注入実験のターゲットになることを許可するかどうかを制御する。簡単に言うと、「このタスクに対して意図的にエラーや遅延などを発生させるテスト（カオステスト的なもの）を行えるようにするか」という設定。通常、本番稼働しているほとんどのアプリケーションでは、このプロパティを明示的に設定する必要はない。デフォルト値はfalse。システムの耐障害性をテストするために、意図的に障害を発生させる実験をSystems Manager Experiment Managerで行う計画がある場合にのみ、true に設定することを検討すべき。特に障害注入実験を行う予定がない場合は、設定しない（デフォルトの false を使用する）のが一般的。

2025-6-18

GitHub Actionsで利用可能なMatrix Strategy（マトリックス戦略）について、いくつかの応用的な使い方を知ることができました。

include：特定の組み合わせを追加する
・マトリックスの基本の組み合わせに加えて、特定の組み合わせを追加したい場合に使用する

exclude：特定の組み合わせを除外する
・特定の組み合わせを実行対象から除外したい場合に使用する

fail-fast：失敗時の挙動を制御する。マトリックス内のいずれかのジョブが失敗した際に、他の進行中のジョブをどうするかを制御する設定。
・fail-fast: true：1つのジョブが失敗すると、残りのすべてのジョブが即座にキャンセルされる。これがデフォルト
・fail-fast: false：1つのジョブが失敗しても、他のジョブはキャンセルされずに最後まで実行される。すべての組み合わせの結果を確認したい場合に設定する

2025-6-19

機密情報を保存する際の選択肢である「SSMパラメータストアでのSecureString」と「AWS Secrets Manager」について、それぞれの特徴を知ることができました。

SSMパラメータストアでSecureString
・主な用途：設定値とシークレットの一元管理
・自動ローテーション：不可（自前でLambda等の実装が必要）
・シークレット生成：不可
・クロスアカウントアクセス：IAMロールの引き受け等が複雑だが、可能ではある
・料金：非常に安価または無料
・主な強み：コスト効率とシンプルさ

Secrets Manager
・主な用途：シークレットのライフサイクル管理
・自動ローテーション：可能（主要な機能）
・シークレット生成：可能（ランダムなパスワード生成等）
・クロスアカウントアクセス：可能（リソースベースのポリシーで簡単）
・料金：高機能な分、高価
・主な強み：シークレットの自動ローテーション

2025-6-20

スワップ領域について知ることができました

スワップ領域とは、物理メモリ(RAM)が不足した際に、ディスクの一部を一時的なメモリとして使用するための仕組み
これにより、メモリ不足によるシステムの不安定化やクラッシュを防ぐことができる

2025-6-23

CloudFormationのモジュール（AWS::CloudFormation::Module）について知ることができました。

CloudFormationのモジュールとは、複数のAWSリソースを一つのまとまりとしてパッケージ化し、再利用可能にするための仕組み。これにより、よく使うリソースの組み合わせ（例えば、S3バケットとそのバケットポリシー、VPCとサブネット群など）を標準化し、様々なCloudFormationテンプレートから簡単に呼び出して使えるようになる。再利用性の向上、標準化とベストプラクティス、テンプレートの簡素化、保守性の向上といったメリットがある。

モジュールの仕組み
モジュールは、通常のCloudFormationテンプレートと同様にYAMLまたはJSONで記述するが、それ自体を直接デプロイするのではなく、CloudFormationレジストリに登録して使用する

1. モジュールの作成：再利用したいリソース群を定義したテンプレートファイルを作成する

2. レジストリへの登録：作成したテンプレートを、AWS::CloudFormation::Module タイプのプライベートリソースとしてアカウント内のレジストリに登録する

3. テンプレートからの利用：親となるテンプレートから、登録したモジュールをあたかも一つのリソースのように呼び出す

2025-6-24

GitHub Actions のマトリックス戦略では、動的な値は読み込めないことを知りました。

strategy.matrix ブロックが評価される段階では、まだ secrets コンテキストにはアクセスできない。ワークフローがジョブを実行する際、まずマトリックスの組み合わせが静的に決定される。この時点では、シークレットのような動的な値はまだ読み込まれていない。

matrix:
    include:
        – service:
            ecr_repository: ${{ secrets.ECR_REPOSITORY_NAME }}

2025-6-25

AWS S3における汎用バケットとディレクトリバケットの違いやそれぞれの特徴について理解することができました。

（汎用バケット）
パフォーマンス：ミリ秒単位のレイテンシー
主な用途：静的ウェブサイト、バックアップ、データレイク、コンテンツ配信など、多岐にわたる一般的な用途
ストレージクラス：S3 Standard、Intelligent-Tiering、Glacierなど複数のクラスを利用可能
可用性と耐久性：複数のAZにデータを複製し、高い可用性 (99.99%) と耐久性を実現
データ構造：フラットなオブジェクトストレージ
料金：ストレージ料金が比較的安価で、リクエスト料金は高め
まとめ：幅広い用途に対応する標準的なストレージ

（ディレクトリバケット）
パフォーマンス：1桁ミリ秒単位の超低レイテンシー
主な用途：機械学習のトレーニング、AI/ML、インタラクティブなデータ分析、メディア処理など、極めて高速な処理が必要なワークロード
ストレージクラス：S3 Express One Zone のみ
可用性と耐久性：単一のAZ内でのみデータを冗長化。そのため可用性はやや低い（99.95%）
データ構造：階層的なディレクトリ構造をサポートし、オブジェクトを高速にリスト化
料金：ストレージ料金は高価だが、リクエスト料金が汎用バケットの約半分と安価
まとめ：超高速アクセスが求められる特定のワークロードに特化した高性能ストレージ

2025-6-26

Amazon S3のTransfer Accelerationという機能について知ることができました。

一言でいうと、遠くの場所からS3バケットへのファイル転送を高速化するための機能。通常、ファイルをS3にアップロードしたり、S3からダウンロードしたりする際は、直接S3バケットがあるリージョンと通信する。しかし、アップロードする場所がS3バケットから地理的に遠い場合、インターネットの経路上で遅延が発生し、転送に時間がかかることがある。S3 Transfer Accelerationを有効にすると、この問題を解決できる。ファイルはまず、ユーザーに最も近いAWSのエッジロケーション（世界中に配置された高速なネットワーク拠点）に送信される。その後、AWSが最適化した高速なプライベートネットワークを経由して、目的のS3バケットまでデータが転送される。

注意点
・追加料金：Transfer Accelerationの利用には、通常のデータ転送量に加えて追加料金が発生する
・専用のエンドポイント：この機能を有効にしたバケットへアクセスするには、通常のエンドポイント（s3.amazonaws.com）ではなく、専用のアクセラレートエンドポイント（s3-accelerate.amazonaws.com）をアプリケーション側で指定する必要がある。CloudFormationで設定を有効にするだけでは、自動的に高速化は適用されない

2025-6-27

ec2-userとは、Amazon EC2上で特定のLinuxディストリビューションのインスタンスを起動した際に、デフォルトで作成されるユーザーアカウントの一種

ec2-userの主な特徴
・デフォルトユーザー：Amazon Linux AMI や RHEL AMI、CentOS AMI など、多くの主要なLinuxディストリビューションのAMIで、インスタンス作成時に自動的に作成される（Ubuntu のAMIでは、ec2-user ではなく ubuntu というユーザーがデフォルトで作成される）
・SSHアクセス：インスタンスへの最初のSSH接続は、通常この ec2-user を使用して行う。キーペア認証と組み合わせて利用される
・sudo権限：ec2-user には、多くの場合、パスワードなしで sudo コマンドを実行できる権限が付与されている。これにより、管理者権限が必要な操作を簡単に行うことができる
・ホームディレクトリ：/home/ec2-user がホームディレクトリとして設定されている