エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。
2025-5-1
ECSタスク定義をcloudformationで行う際に、ContainerDefinitions > LogConfiguration > Options > awslogs-create-log-group プロパティをtrueにすると、awslogs-group で指定したロググループが存在しない場合に、ECSが自動的にロググループを作成してくれることを知りました。
・ただし、推奨されるのはロググループの作成もCloudFormationで行うこと
・理由は、ロググループの保持期間などの設定をCloudFormationで制御できるようになるため
・自動作成だとデフォルトの設定になってしまう
2025-5-2
過去に作成されたEBSボリュームのスナップショットに付与されていた下記の説明は、AWSが別のプロセス（ここではAMI作成）の副産物として自動的に付与した説明であることを知りました。
Created by CreateImage(i-000000) for ami-11111111111 from vol-222222
・Created by CreateImage(…) という部分は、そのスナップショットがEC2インスタンスからAMIを作成する処理によって生成されたことを示している
・(i-000000) は、そのAMIを作成するために元になったEC2インスタンスID
・for ami-11111111111 は、このスナップショットがどのAMIの構成要素として作成されたか（AMIのID）を示している
・from vol-222222 は、このスナップショットが、元のどのEBSボリューム (vol-222222) のバックアップとして取られたかを示している
EBSボリュームがアタッチされていたEC2インスタンスからAMIを作成した際に、AWSが自動的にそのボリュームのスナップショットを作成し、AMIに紐づけ、この説明を自動で付与した
2025-5-7
Dynamo DBのキャパシティモードの変更は、24時間に1回のみ可能であることを知りました。
2025-5-8
ECSタスク定義にて、新たに「コンテナ名:ContainerPort」の組み合わせを追加し、それをALBからルーティングしたい場合は、下記手順で対応すれば良いことを知りました。
1. その新しい組み合わせに対応する新しいターゲットグループを作成する
2. ECSサービス定義のLoadBalancersプロパティにて、作成した新しいターゲットグループのARNと、追加した「コンテナ名:ContainerPort」の組み合わせを追加し、CloudFormationでサービスを更新
3. CloudFormationによるサービス更新の結果、ECSは新しいタスク定義リビジョンでタスクを再起動（置き換え）し、新しく起動したタスクを、既存のターゲットグループに加えて、追加した新しいターゲットグループにも自動的に登録する
2025-5-9
Pythonによって自動的に定義, 設定される特別な変数 __name__ について知ることができました。
Pythonがスクリプトを実行する際に、そのスクリプトがどのように起動, 実行されているかに応じて、__name__変数に自動的に値が設定される
具体的には、以下のようになる
・ファイルが直接実行された場合：そのスクリプトの __name__ は文字列 “__main__” になる
・ファイルが他のスクリプトからモジュールとしてインポートされた場合：そのスクリプトの __name__ は、モジュール名（ファイル名から .py を除いたもの）になる
2025-5-12
WafCharmについて知ることができました。
WafCharmとは、AWS WAF、Azure WAF、Google Cloud Armor といった主要なクラウドプラットフォームが提供するWAFのルールを自動で最適化・運用するサービス。AIとビッグデータを活用し、ウェブサイトやウェブアプリケーションへの攻撃パターンを分析・学習することで、最適なWAFルールを自動的に作成・適用する。
主な特徴
・WAFルールの自動運用: AIが最新の脅威情報やお客様の環境に合わせてWAFルールを自動で最適化・運用するため、専門知識がなくても効果的なセキュリティ対策が可能
・誤検知の低減: AIによる機械学習で、正常なアクセスを誤ってブロックしてしまう「誤検知」を最小限に抑える
・新種の脅威への対応: 新しい脆弱性や攻撃手法にも迅速に対応し、常に最新のセキュリティ状態を維持する
・運用負荷の軽減: WAFのルール設定やチューニングといった専門的な作業をWafCharmが代行するため、情報システム担当者の運用負荷を大幅に軽減できる
・日本語サポート: 日本の企業が開発・提供しているサービスであり、日本語での手厚いサポートが受けられる
WafCharmを利用することで、企業はサイバー攻撃から自社のウェブサイトやウェブアプリケーションを効果的に保護し、セキュリティ運用にかかるコストや手間を削減することができる
2025-5-13
CloudWatch LogsのLogGroupClassについて知ることができました。
LogGroupClassとは、ログデータを保存およびアクセスするためのストレージクラスを指す。これにより、ログのアクセス頻度と必要な機能に応じてコストを最適化できる。CloudWatch Logs には、主に以下の 2 つのログクラスがある。
Standardクラス
これは従来のデフォルトのログクラス。CloudWatch Logs のすべての機能（メトリクスフィルター、サブスクリプションフィルター、S3 へのエクスポート、Contributor Insights など）を完全にサポートしている。リアルタイムの監視や頻繁な分析が必要なログに適している。取り込み料金は Infrequent Access クラスよりも高くなる。
Infrequent Access (Standard-IA) クラス
アクセス頻度の低いログ向けに設計された新しいログクラス。Standard クラスと比較して、データ取り込みの料金が低く設定されている。主にアドホックなクエリや事後フォレンジック分析に最適。ただし、Standard クラスの一部の機能（サブスクリプションフィルター、S3 へのエクスポート、Anomaly Detection など）はサポートされていない。コストを抑えつつ、必要に応じてログデータを検索・分析したい場合に有効。
LogGroupClassを選択する際の考慮事項
1.アクセス頻度
ログにどのくらいの頻度でアクセスし、分析する必要があるかを検討する。リアルタイムの監視や頻繁なトラブルシューティングが必要な場合はStandardクラス、たまにしか参照しないアーカイブ目的のログなどはInfrequent Accessクラスが適している。
2. 必要な機能
サブスクリプションフィルターを使ったリアルタイム処理や S3 へのエクスポートが必要かどうかを確認する。これらの機能が必要な場合は Standard クラスを選択する必要がある。
3. コスト
取り込みデータ量が多い場合、Infrequent Access クラスを選択することでコストを削減できる可能性がある。料金体系を確認し、ユースケースに応じたクラスを選択することが重要。
一度作成したロググループのクラスは変更できないため、ロググループ作成時に慎重に選択する必要がある。これらのログクラスを選択することで、CloudWatch Logs の利用コストを最適化しつつ、ログ管理の要件を満たすことができる。
2025-5-14
rsyslogについて知ることができました。
rsyslogとは、システムロギングデーモン（サービス）
具体的には、以下のような役割を果たす
1. ログの収集：Linuxシステム上で動作する様々なアプリケーションやサービス（例、postfixやdovecot、PHPスクリプト、カーネルなど）が出力するログメッセージを収集する
2. ログの処理と転送：収集したログメッセージを、設定に基づいて処理する。例えば、特定のログをファイルに書き出したり、ネットワーク経由で他のログサーバーに転送したり、データベースに保存したりすることができる
3. 高機能なロギング：従来のsyslogdに比べて、より高機能で柔軟な設定が可能。TCPでのログ転送、TLSによる暗号化、ログメッセージのフィルタリング、出力フォーマットのカスタマイズなどに対応している
2025-5-15
Vimで1行削除するには、まず削除したい行に移動し、その後 dd と入力すると削除されることを知りました。また、複数行を削除する場合は、削除したい行数 + dd と入力すれば良いことを知りました (例: 5dd で5行削除)
2025-5-16
sam deploy コマンドに –force-upload オプションを付与した際の挙動について知ることができました。
・このオプションは、ローカルのアーティファクト（Lambda関数のコードやその他のファイル）がS3バケットに既に存在する場合でも、強制的に再アップロードするよう指示する
・通常、sam deploy を実行すると、SAM CLIはローカルのアーティファクトのハッシュ値を計算し、S3バケットに既に同じハッシュ値のファイルが存在するかどうかを確認する
・もし同じものが存在すれば、アップロードをスキップしてデプロイ時間を短縮する
・しかし、–force-upload を指定すると、このハッシュ値の比較を行わず、常にローカルのファイルをS3バケットにアップロードする
2025-5-19
ECSタスク定義で、既存の「コンテナ名：ContainerPort」の組み合わせを削除し、もうALBからそこにルーティングする必要がない場合、下記の流れでリソースのクリーンアップが行われることを知りました。
1. ECSサービス定義のLoadBalancersプロパティから、その組み合わせに関連付けられていたターゲットグループのエントリを削除して、CloudFormationでサービスを更新する
2. これにより、ECSはそのターゲットグループへのタスク登録/解除の管理を行わなくなる
3. 不要になったターゲットグループリソース自体も、CloudFormationテンプレートから削除してスタックを更新することで、リソースをクリーンアップする
2025-5-20
API Gatewayを使う代表的なシーンを知ることができました。
外部公開のエンドポイントが必要
インターネット経由でクライアント（ブラウザやモバイルアプリなど）が直接呼び出すAPIを持つ場合。API GatewayでHTTPS終端、カスタムドメイン設定、WAF連携などを行い、セキュリティとスケーラビリティを簡単に担保できる。
リクエスト/レスポンスの変換や認証, 認可が必要
OAuth2/Cognitoなどを用いた認証、APIキーによる認可、ステージ管理、Rate Limiting（割り当て制限）など。特にREST API GatewayやHTTP API Gatewayには、ステージ別デプロイ/キャパシティ設定/Usage Plans といった機能がある。
Lambdaを簡単に公開したい
Lambdaを直接HTTP呼び出し可能にしたい場合はAPI Gatewayがあると便利（ただし近年は「Lambda Function URL」機能もある）。
サーバレス＆イベント駆動を活用する構成
API Gateway → Lambda → DynamoDBやStep Functionsなどのワークフロー。なるべくEC2やECSのホスティングを使わずに済ませたい場合。
複数マイクロサービスの集約ポイント
「API Gatewayをフロントにして様々なバックエンドサービスに振り分ける」アーキテクチャ。システム全体で統一のエンドポイントを提供する際など。
2025-5-21
ブラウザはセキュリティやパフォーマンスの観点からリダイレクト回数に制限を設けていることを知りました。
2025-5-22
GAという表現を知ることができました。
GA = General Availability（正式版）
GAとは、安定した正式リリース（一般提供版） を指す
2025-5-23
シェルの行継続文字 \ が行末で終わると、ランナーが「入力待ち」になり、最終的にジョブがタイムアウトする挙動をとることを知りました。これより、わずかながらオーバーヘッドが発生することになるので、コマンドの実行自体に影響は出ないものの、コマンド末尾の \ はしっかり削除すべきであることを知りました。
2025-5-26
EBSボリュームにおけるAZの制約について知ることができました。
・EBSボリュームは、特定のAZ内に作成される
・ボリュームをアタッチできるのは、同じAZにあるEC2インスタンスのみ
・異なるAZにあるインスタンスには直接アタッチできない（スナップショットを作成し、そのスナップショットから別のAZに新しいボリュームを作成することは可能）
2025-5-27
cloudformationで２つのAuroraインスタンスリソース定義を行い、例えば前者リソース定義をプライマリ（ライター）インスタンス、後者リソース定義をリードレプリカ（リーダー）インスタンスとして構築したい場合、後者リソース定義で「DependsOn 前者リソース論理名」を記述し、前者リソースの構築が完了してから後者リソースの構築を実施するように制御する必要があることを知りました。
もともと自分は、PromotionTierプロパティ（フェイルオーバー時にマスターインスタンスへと昇格させるレプリカインスタンス間での優先順位を指定するプロパティ）により、マスターとレプリカどちらのインスタンスとして構築されるかコントロールされるのかと思っていました。具体的には、マスターインスタンスリソース定義ではPromotionTierプロパティを指定せず、レプリカインスタンスのみPromotionTierプロパティを指定する認識でいました。そして、この指定でデプロイしたところ、見事にマスターとレプリカが逆転しました。「レプリカインスタンスを想定したリソース」の構築が「マスターインスタンスを想定したリソース」の構築より先に終わり、これより逆転しました。この経験を通して、構築が完了する順序によってマスターとレプリカが決まることを知りました。なので、DependsOnによる作成順序制御の機構を追加した次第です。そして、PromotionTierプロパティはフェイルオーバー時の上述の動作を決定するだけのプロパティであり、インスタンス構築時の挙動には関与しないことを知りました。正しい知識に修正することが出来て良かったです。
2025-5-28
LaravelアプリケーションをECSでデプロイする際に、Dockerfile内でphp artisan config:cacheすると、ECSタスク定義でコンテナへの注入設定をした環境変数が実質注入されていないことになることを知りました。
（詳細）
Dockerfile 内で php artisan config:cache を実行すると、Dockerイメージがビルドされる時点で bootstrap/cache/config.php というキャッシュファイルが作成される。このキャッシュファイルには、そのビルド時に参照可能だった環境変数の値がハードコードされる。その後、ECSタスクが起動する際にSecrets Managerから取得したシークレットが環境変数としてコンテナに注入される。しかし、Laravelアプリケーションは起動時に bootstrap/cache/config.php が存在すると、そのキャッシュファイルを優先して読み込む。その結果、ECSによって後から注入された環境変数は、キャッシュされた設定値によって上書きされるか、あるいはキャッシュ作成時に存在しなかったために反映されない、という現象が発生する。
自分がこの事象に遭遇した際は、Dockerfile 内における php artisan config:cache コマンドを削除することで対応しました。フレームワークの内部の動きを知っておくことの重要性を感じました。
とはいえ、パフォーマンス向上のために config:cache を利用したい場合は、Dockerイメージのビルド時ではなく、コンテナの起動スクリプト（entrypointスクリプトなど）内でphp artisan config:cacheを実行する方法が１つあることを知りました。
1. ECSがシークレットを環境変数としてコンテナに注入
2. コンテナのentrypointスクリプトが実行される
3. entrypointスクリプト内で php artisan config:cache を実行する。この時点では既にシークレットが環境変数として存在するため、正しい値で設定キャッシュが作成される
4. その後、Webサーバー（Nginxなど）やPHP-FPMを起動する
2025-5-29
AMIの中で、プライベートイメージと無効化されたイメージがどういったイメージか知ることができました。
プライベートイメージ
他の特定のAWSアカウントから、自分のアカウントに対して明示的に共有が許可されたAMI。そのAMIの所有者は別のアカウントだが、自分らはそのAMIを使用して自分のEC2インスタンスを起動する権限を与えられている。例えば、ある開発チームが作成した共通のベースAMIを、チーム内の他のメンバーアカウントにプライベートに共有する、といったケースで利用される。パブリックには公開されていないが、限られた範囲で共有したい場合に便利。自己所有イメージは文字通り自分のものだが、プライベートイメージは他人から「使っていいよ」と許可されたもの、という違いがある。
無効化されたイメージ
何らかの理由で、現在はインスタンスの起動には使用できない、または使用が推奨されなくなったAMI。
無効化となるケース
・AMIの登録解除：AMIの所有者がそのAMIの登録を解除した場合。登録解除されたAMIは新しいインスタンスの起動には使用できなくなるが、そのAMIから過去に起動されたインスタンスには影響しない
・非推奨化：AWSやAMIの提供元が、古いバージョンである、セキュリティ上の懸念がある、などの理由でそのAMIの使用を推奨しなくなった場合
・特定のAMIが、特定のリージョンでのみ利用不可になった場合など、技術的な制約によるもの
2025-5-30
/etc/httpd/conf.d ディレクトリがどういったディレクトリなのか知ることができました。
このディレクトリは、Apache HTTP Server（httpd）の追加の設定ファイルを格納するための標準的な場所
/etc/httpd/conf.dの役割は下記
1. モジュール化された設定：Apacheのメイン設定ファイル（/etc/httpd/conf/httpd.conf など）を直接編集する代わりに、このディレクトリに .conf 拡張子を持つファイルを作成することで、設定をモジュール化できる
2. 読み込み：メイン設定ファイル（httpd.conf）の中で、通常 IncludeOptional conf.d/*.conf のようなディレクティブによって、このディレクトリ内の .conf ファイルが自動的に読み込まれるようになっている
3. 管理の容易さ：機能ごとやバーチャルホストごとに設定ファイルを分割して管理できるため、設定の見通しが良くなり、管理が容易になる。例えば、特定のウェブアプリケーション用の設定や、SSLの設定などを個別のファイルとしてここに配置することが一般的
4. パッケージによる追加設定：Apacheのモジュールや関連ソフトウェアをパッケージマネージャー（yum や dnf など）でインストールすると、それらの設定ファイルが自動的にこのディレクトリに配置されることもよくある
したがって、/etc/httpd/conf.d はApacheの動作をカスタマイズするための重要な設定ファイル群が置かれるディレクトリと言える。