エンジニアとして日々新しい知識をインプットしています。現在の職場には、毎日の終業時に日報を提出する文化があり、その中に「本日発見したこと・気づいたこと」を記載する欄が設けられています。私はこの欄を、業務で得た新しい知見や、業務外の自己学習で学んだことを記録するアウトププットの場として活用しています。この記事は、その日々の学びを知識として定着させ、いつでも振り返れる資産にするために、1ヶ月分をまとめたものです。
2025-4-1
通常のメール送信では、送信元ドメインのメールサーバーが宛先ドメインのメールサーバーに直接接続, 送信しようとするのが基本だと思いますが、途中で他のSMTPサーバーによって中継が発生するケースとして下記が挙げられることを知りました。
1. 組織内の経路：送信する人のPCから、その人が所属する組織のメインのメールサーバー（外部と通信するサーバー）に到達するまでに、組織内の複数のサーバー（例：セキュリティチェック用、部署ごとのサーバーなど）を経由することがある。これは組織内部の話。
2. スマートホスト/リレー設定：組織によっては、全ての送信メールを特定の信頼できる中継サーバー（スマートホスト）を経由するように設定している場合がある。これは意図的な設定（ベアメールのような外部リレーサービス利用もこれに該当）。
3. 過去の技術（ストアアンドフォワード）：インターネット接続が不安定だった時代には、直接宛先に届けられない場合に一時的に他の中継サーバーに預けて再送を試みる仕組みがあったが、現在ではあまり一般的ではない
2025-4-2
ECRにおけるパブリックレジストリとプライベートレジストリの違いについて知ることができました。
パブリックレジストリ（ECR Public）の特徴
・主な目的：インターネット全体へのイメージの公開・配布（オープンソースなど）
・アクセス制御：緩やか。イメージのプル（ダウンロード）は基本的に認証不要。プッシュには AWS 認証が必要。
・レジストリ URI：public.ecr.aws（例：public.ecr.aws/エイリアス/リポジトリ名）
・ユースケース：OSS、公開ツール、チュートリアル用イメージ、Docker Hub の代替
・料金：ストレージ量、データ転送量（特に外部へのプル）に基づく（無料利用枠あり）
プライベートレジストリ（ECR Private）の特徴
・主な目的：組織内や特定ユーザー間での非公開イメージの保管・共有
・アクセス制御：厳格。IAM ユーザー/ロール、リソースベースポリシーで制御。プル/プッシュ共に認証が必須
・レジストリ URI：AWSアカウントID.dkr.ecr.リージョン.amazonaws.com
・ユースケース：企業アプリ、機密情報を含むイメージ、開発/ステージング環境
・料金：データ転送量、ストレージ量に基づく（無料利用枠あり）
2025-4-3
SASL認証について理解することができました。
SASLとは「Simple Authentication and Security Layer」の略。様々な通信プロトコル（例、メール送受信のSMTPやIMAP/POP3、ディレクトリサービスのLDAPなど）を用いて、安全かつ柔軟にユーザー認証やデータのセキュリティ対策（完全性や機密性の保護）を行うための１つの仕組み。「どのようにユーザーを認証するか」という具体的な方法（メカニズム）を、プロトコル自体とは切り離して柔軟に扱える。利用するプロトコルやセキュリティ要件に応じて、適切なSASLメカニズムを選択することが大切。
主な特徴と仕組み
１、プロトコルと認証メカニズムの分離
SASLを使うと、通信プロトコル側は「SASLを使って認証する」とだけ決めておけば、具体的な認証方法（パスワードをどう送るか、など）はSASLの「メカニズム」に任せることができる。これにより、プロトコル自体を変更しなくても、新しい認証方式（メカニズム）を追加したり、セキュリティ要件に合わせて変更したりすることが容易になる
２、ネゴシエーション（交渉）
クライアント（例：メールソフト）がサーバー（例：メールサーバー）に接続する際、まずサーバーが「私はこれらのSASL認証メカニズムに対応していますよ」というリストを提示する。クライアントはそのリストの中から、自分が対応していて、かつ使いたいメカニズムを選び、サーバーに伝える。こうして、どの認証メカニズムを使うかが決まる。
３、認証情報の交換
選ばれたメカニズムの手順に従って、クライアントとサーバー間で認証情報が交換される。単純なユーザー名/パスワードを送る方式（PLAINなど）もあれば、チャレンジ/レスポンス方式（CRAM-MD5, DIGEST-MD5, SCRAMなど）のように、パスワードそのものをネットワークに流さずに認証を行う、より安全な方式もある。
４、セキュリティレイヤー（オプション）
認証が成功した後、選んだメカニズムによっては、その後の通信内容を保護するための「セキュリティレイヤー」を確立できる。これにより、通信内容の改ざんを防いだり（完全性保護）、暗号化したり（機密性保護）することが可能。どの程度の保護を提供するかは、SSF（Security Strength Factor）という数値で示される。
2025-4-4
SASL認証メカニズムの主な種類について知ることができました。
SASLには様々な認証メカニズムがあり、それぞれセキュリティ強度や特徴が異なる。
PLAIN：ユーザー名とパスワードを単純にBase64エンコードして送信する。簡単だが、通信経路が暗号化されていないと盗聴される危険性が高い
LOGIN：PLAINと似ているが、ユーザー名とパスワードを別々のステップで送信する。同様にTLS/SSLによる暗号化が必須
CRAM-MD5：サーバーが送ってきた「チャレンジ」と呼ばれるランダムな文字列と、クライアントが持つパスワードを使って計算したハッシュ値を送り返す。パスワード自体はネットワークに流れない
DIGEST-MD5：CRAM-MD5を拡張したもので、相互認証（クライアントがサーバーを、サーバーがクライアントを認証する）などが可能
SCRAM（例：SCRAM-SHA-1, SCRAM-SHA-256）：CRAM-MD5やDIGEST-MD5よりも強力なハッシュ関数（SHA-1やSHA-256）とソルト（パスワードに付加するランダムな値）を使い、より安全性を高めたチャレンジ/レスポンス方式。最近推奨されることが多いメカニズム
GSSAPI：Kerberosなど、より高度な認証基盤システムを利用するためのメカニズム。企業ネットワークなどで使われることがある
EXTERNAL：TLS/SSLのクライアント証明書など、SASLの認証プロセス外で既に確立されている認証情報を使って認証を行う方式
ANONYMOUS：認証を行わず、匿名でのアクセスを許可する場合に使う
2025-4-7
Dovecotについて知ることができました。
Dovecotとは、受信したメールをユーザーがアクセスするためのMDA（Mail Delivery Agent）の一部機能（特にIMAP/POP3によるアクセス部分）を担うOSS。ユーザーがメールを安全かつ効率的に読み書きするための重要なコンポーネント。
主な役割
Postfixが受け取ったメールを最終的にユーザーのメールボックスに保存する。メールサーバー（メールボックス）に保存されているメールを、ユーザーがメールクライアント（Outlook, スマートフォンのメールアプリなど）を使って読み書き（アクセス）できるようにする機能の提供。SASL認証機能の提供。
主な特徴
・セキュリティ：セキュリティを重視して設計されている
・パフォーマンス：高速かつ安定しており、多くの同時接続を効率的に処理できる
・柔軟性：様々なメールボックス形式（Maildir, mboxなど）や認証方法（システムユーザー、SQLデータベース、LDAPなど）に対応している
・設定の容易さ：他のIMAP/POP3サーバーと比較して設定が比較的容易であると言われている
・標準準拠：IMAPやPOP3の標準規格に準拠している
2025-4-8
Dovecotが持つSASL認証機能について理解することができました
Dovecotは、非常に強力で柔軟な認証機能を持っている。Dovecotは、様々な認証バックエンド（OSのユーザー、データベース、LDAPなど）に柔軟に対応でき、設定も比較的容易。これより、PostfixもSASL認証機能を持っているが、Postfixは自身で認証処理を行わず、Dovecotの認証機能（SASL経由）を利用することが一般的。つまり、ユーザーがメールを送信しようとすると、PostfixはDovecotに認証を依頼する、そしてDovecotが認証を行う。このような連携をとる。ユーザーのメールクライアントからのメール読み取りアクセス（IMAP/POP3）時の認証は、もちろんDovecot自身が行う。
2025-4-9
Postfixのanvilサービスについて知ることができました。
Postfixのanvilサービスとは、クライアント（メールを送ってくるサーバーやメールソフト）ごとの接続頻度（レート）や同時接続数を監視し、制限する役割を持っている。これにより、特定のクライアントからの過剰な接続（例えば、DoS攻撃やパスワード試行など）を防ぐことができる。
2025-4-10
シェルスクリプトの中で使われるコマンド「set -e」について、どのようなコマンドか知ることができました。
このコマンドは、スクリプト内でいずれかのコマンドがエラー（非ゼロの終了ステータス）で終了した場合、スクリプト全体の実行を直ちに停止するように設定する
目的１
エラー発生時の即時停止：通常、シェルスクリプトは途中でエラーが発生しても、後続のコマンドを実行し続ける。set -e を使うことで、エラーが発生した時点でスクリプトが停止するため、意図しない動作や連鎖的なエラーを防ぐことができる。
目的２
確実な実行：特に設定ファイルを作成したり、システムの状態を変更したりするスクリプトでは、途中のステップが失敗した場合にそのまま続行すると問題が発生する可能性がある。set -e は、各ステップが成功することを前提として処理を進め、失敗した場合は安全に停止させるために役立つ。
2025-4-11
Auroraのクォーラムベースのストレージシステムについて知ることができました。
・Auroraはクォーラムベースのストレージシステムに基づいている
書き込み可用性（最大2コピー損失）
書き込みを正常に完了するには、6つのコピーのうち少なくとも4つからの応答が必要。したがって、最大で2つのコピーが利用不可能になっても（例：1つのAZが完全に停止してその中の2コピーを失う）、残りの4つで書き込みを継続できる。3つのコピーを失うと書き込みクォーラム（4）を満たせなくなり、書き込みが停止する。
読み取り可用性（最大3コピー損失）
読み取りを正常に完了するには、6つのコピーのうち少なくとも3つからの応答が必要。したがって、最大で3つのコピーが利用不可能になっても（例：1つのAZが完全に停止し、さらに別のAZで1コピー失う）、残りの3つで読み取りを継続できる。4つのコピーを失うと読み取りクォーラム（3）を満たせなくなり、読み取りもできなくなる。
2025-4-14
Dockerのbuildxについて理解することができました。
buildxとは、Docker CLIのプラグイン。Dockerのビルド機能を強化するBuildKitというバックエンドエンジンの能力を最大限に引き出すためのインターフェースとして開発された。BuildKit自体は、Docker Engineに統合されつつあるが、その高度な機能（マルチプラットフォームビルド、効率的なキャッシュ管理、並列ビルドステージ実行など）をフル活用するには、buildxを使うのが一般的。buildxを使わずに、標準のdocker buildだけで異なるアーキテクチャ向けのイメージをビルドするのは、通常はできない（クロスコンパイル用のツールチェインをDockerfile内で複雑に設定するなど、特別な工夫が必要になる）。
2025-4-15
サイクロマチック複雑度について知ることができました
サイクロマチック複雑度（Cyclomatic Complexity）とは、ソフトウェアのソースコードの複雑さを測るための指標（メトリクス）の一つ。主に、プログラムの制御フローの複雑さを定量的に示す。あくまで制御フローの複雑さを示す指標であり、コードの行数やデータ構造の複雑さなどは直接反映しない。提唱者であるトーマス・J・マッケイブ（Thomas J. McCabe）の名を取って、マッケイブ複雑度とも呼ばれる。
（特徴１）複雑度の定量化：プログラムがどれだけ多くの分岐（if文、for文、while文など）を持っているか、つまり、どれだけ多くの実行経路（パス）が存在しうるかを示す
（特徴２）テスト容易性の指標：この値が高いほど、プログラムの構造が複雑であり、全ての経路をテストするためにはより多くのテストケースが必要になることを意味する。一般的に、サイクロマチック複雑度は、プログラムの全経路を網羅するために最低限必要なテストケース数と関連付けられる。
（特徴３）保守性の指標：リファクタリングが必要な箇所を特定する目安としても利用される
2025-4-16 ①
GitHub Actionsのpathsオプションについて知ることができました。
pathsオプションは、特定のファイルやディレクトリに変更があったときのみワークフローを実行させたい場合に使える。これは主に on.push や on.pull_request の中で使われる。
（src/以下のファイルや README.md に変更があった場合にのみワークフローが実行される例）
on:
push:
paths:
– ‘src/**’
– ‘README.md’
docs/ 以下のファイルが変更された PR のみワークフローが走る例
on:
pull_request:
paths:
– ‘docs/**’
2025-4-17
上記とは反対に、除外したい場合は paths-ignore を使えることも知りました。
（docs/ や README.md にしか変更がなかった場合はワークフローをスキップする例）
on:
push:
paths-ignore:
– ‘docs/**’
– ‘README.md’
paths で !src/** のようにすることでsrc/以下を除外することもできるが、paths-ignoreを使う方が一般的
2025-4-18
AWS cloudformationにて、Type: AWS::EC2::Subnetに存在するEnableDns64プロパティ（Boolean）について理解することができました
・サブネットで DNS64 を有効にするかどうかを指定する
DNS64とは、IPv6-only クライアントから IPv4-only 宛先への通信を可能にするための仕組み。利用する機会は比較的限られるが、IPv6-only 環境で IPv4 と通信が必要になる場合などに使用する。DNS64は 、DNS サーバが Aレコード（IPv4アドレス）のみしか存在しないドメインに対して、AAAAレコードを偽装して返す機能。返された偽装アドレスを通じて、ネットワーク内部では NAT64 が IPv6 → IPv4 のパケット変換を行うことで通信が可能になる。AWS の VPC サブネット設定で EnableDns64 を有効にすると、VPC がその仕組みを提供してくれる。典型的には、インターネット向けに IPv4-only サービスにアクセスする際や、オンプレ（IPv4-only）と VPC（IPv6-only）を接続するシナリオなどで使われる。
2025-4-21
ALBのデュアルスタックモードについて知ることができました。
概要
これはALBがIPv4とIPv6の両方のトラフィックを処理できるようにするための機能。多様なクライアントからのアクセスを単一のロードバランサーで受け付けられるようになる。
両方のIPバージョンに対応
デュアルスタックモードを有効にすると、ALBにはIPv4アドレス用のDNSレコード（Aレコード）と、IPv6アドレス用のDNSレコード（AAAAレコード）の両方が自動的に割り当てられる。これにより、クライアントはIPv4ネットワークからでも、IPv6ネットワークからでも、同じALBのDNS名を使ってアクセスできるようになる。
クライアント接続
IPv4のみを使用するクライアントは、ALBのAレコードを解決してIPv4アドレスで接続する。IPv6を使用するクライアントは、ALBのAAAAレコードを解決してIPv6アドレスで接続する。クライアントのネットワーク環境に応じて、適切なIPバージョンでALBに接続できる。
ALBからターゲットへの接続
クライアントがIPv6でALBに接続した場合でも、ALBからバックエンドターゲットへの接続は、ターゲットグループの設定に依存する。ターゲットグループの「IPアドレスタイプ」設定が IPv4 であれば、ALBはターゲットにIPv4で接続する。ターゲットグループの「IPアドレスタイプ」設定が IPv6 であれば、ALBはターゲットにIPv6で接続する（ただし、ターゲットがIPv6に対応している必要がある）。つまり、ALBがクライアントからのIPv6接続を受け付け、内部のIPv4のみで構成されたバックエンドサーバー群へトラフィックを転送する、といった構成が可能。これにより、バックエンドターゲットはすぐにIPv6対応させなくても、IPv6クライアントからのアクセスを提供できる。
デュアルスタックモードのメリット
・到達性の向上：IPv6のみのネットワーク環境からのアクセスも可能になる
・段階的なIPv6移行：バックエンドのインフラをすぐにIPv6対応させなくても、フロントエンド（ALB）でIPv6アクセスを提供開始できる
・単一のエンドポイント：クライアントは、自身のIPバージョンに関わらず、同じALBのDNS名を使用できる
・将来性：インターネットにおけるIPv6の普及に対応できる
考慮事項１
VPCとサブネットのIPv6設定：デュアルスタックモードを使用するには、VPCとALBを配置するサブネットでIPv6が有効になっている（IPv6 CIDRが割り当てられている）必要がある
考慮事項２
ALBのセキュリティグループでは、許可するソースIPとして、従来のIPv4アドレス範囲 (0.0.0.0/0 など) に加えて、IPv6アドレス範囲 (::/0 など) からのインバウンドトラフィック（例：ポート80, 443）を許可する必要がある
2025-4-22
DeletionPolicy: Retainの挙動について知ることができました。
DeletionPolicy: Retainを設定したAWSリソースは、CloudFormationスタックからそのリソース定義が削除されたり、スタック全体が削除されたりする際に下記の挙動をとる
CloudFormationの管理下から外れる
CloudFormationは、スタックの削除（またはリソース定義の削除に伴うスタック更新）のプロセスの一環として、その論理リソーススタックを管理対象から外す
物理リソースは削除されない
DeletionPolicy: Retainが指定されている場合、CloudFormationは物理リソースを削除するAPIコールは発行しない。つまり、結果として物理的なリソースは削除されず維持（保持）される
維持されたリソースはCloudFormationとは独立した存在となり、CloudFormationがその後再度管理することはない。
手動で削除するか、別のCloudFormationスタックで Resource Import 機能を使って既存リソースとして管理下に置くなどの操作を行わない限り、アカウント内に残り続ける
スタックを削除してもリソースは削除されず残ることは分かっていましたが、元々そのリソースを管理していたスタックとの関係性がどうなるのか認識できていなかったため、そこを理解することができて良かったです。
2025-4-23
EC2インスタンスとEBSボリューム間でのアタッチにおける関係性について理解することができました。
1つのEC2インスタンスは、複数のEBSボリュームをアタッチ可能。一般的な構成として、1つのEC2インスタンスに、以下のように複数のEBSボリュームをアタッチすることがよくある。
1. ルートボリューム：1つ。OSや基本的なアプリケーションがインストールされている（例：/dev/sda1）
2. データボリューム：1つまたは複数。アプリケーションデータ、データベースファイル、ログファイルなどを保存するために追加する（例：/dev/xvdf, /dev/xvdg など）
このように、用途に応じて複数のボリュームを使い分けることで、以下のようなメリットがある。
・データ管理の分離：OSとアプリケーションデータを分けることで、バックアップやリストア、ボリュームサイズの変更などが容易になる
・パフォーマンスの最適化：用途に合わせて異なるボリュームタイプ（例: OSはgp3、データベースはio1）を選択可能
・スナップショット戦略：ボリュームごとに異なる頻度や保持期間でスナップショットを取得できる
インスタンスタイプごとにアタッチできるEBSボリュームの数には上限があるが、ほとんどのユースケースでは十分な数がサポートされている。まとめると、EC2インスタンスとEBSボリュームの関係は1対多であり、1つのインスタンスが必要に応じて複数のボリュームを利用することが可能。
一方で、1つのEBSボリュームは通常、同時に1つのEC2インスタンスにしかアタッチできない。しかしio1およびio2ボリュームタイプでは、Multi-Attach EBSという機能が提供されており、特定の条件下で複数のインスタンスから同時にアタッチすることが可能（ただし、ファイルシステムの整合性を保つための考慮が必要）
2025-4-24
IOPSについて色々知見を深めることができました。
IOPSとは、ストレージデバイス（HDDやSSDなど）の性能を表す重要な指標の一つ。正式名称は、Input/Output Per Second（1秒あたりの入出力回数）。ストレージデバイスが1秒間に処理できるデータの読み書き（I/O）の回数を示す。数値が大きいほど、より多くの読み書き要求を短時間で処理できるため、高性能であると言える。
なぜIOPSが重要か
IOPSは、特にランダムアクセスの性能を評価する上で重要。ランダムアクセスとは、データの格納場所が連続しておらず、ディスク上の様々な場所に散らばっているデータにアクセスすること。
以下のような用途では、IOPSの高さがシステムの快適さや処理能力に直結する
・データベース：多数のユーザーが同時に様々なデータにアクセスするため、ランダムアクセス性能が重要になる
・仮想化環境：複数の仮想マシンが同時にストレージへアクセスするため、高いIOPSが求められる
・ファイルサーバー：多くのユーザーが様々なファイルにアクセスするため、ランダムアクセスが多く発生する
・OSやアプリケーションの起動、動作：細かいファイルの読み書きが頻繁に発生するため、ランダムアクセス性能が影響する
IOPSには主に以下の種類がある
・ランダムIOPS：ディスク上のランダムな位置にあるデータに対する読み書き性能を示す。上記のような用途で特に重要視される
・シーケンシャルIOPS：ディスク上で連続した領域にあるデータに対する読み書き性能を示す。大きなファイルのコピーや動画編集などではこちらが重要だが、一般的にランダムIOPSほどシステムの体感速度に影響しないことが多い
また、読み込み（Read）と書き込み（Write）それぞれでIOPSの値は異なるため、「ランダムリードIOPS」「ランダムライトIOPS」のように分けて表記されることもある
IOPSとスループット（MB/sなどで表される転送速度）の違い
・IOPS：1秒間に「何回」読み書きできるか（アクセス回数）
・スループット：1秒間に「どれだけのデータ量」を転送できるか（データ転送量）
両者は関連しているが、意味するものは異なる
・細かいデータを頻繁に読み書きする場合 → IOPSが重要
・大きなデータをまとめて読み書きする場合 → スループットが重要
まとめ
・IOPSは、ストレージが1秒間に処理できる読み書きの回数を示す指標
・特にデータベースや仮想環境など、ランダムアクセスが多い用途ではシステムの性能を左右する重要な要素となる
・スループット（転送速度）とは異なる指標であり、用途に応じてどちらを重視すべきか判断する必要がある
2025-4-25
通常、CloudFormationは1つの値に対して1つの短縮形タグ（!Ref, !Sub, !ImportValue など）を期待しているため、下記のような記述はエラーになることを知りました。
SubnetIds:
– !ImportValue !Sub “${NetworkStackName}-RDSSubnet1aId”
（正しい構文1）
SubnetIds:
– !ImportValue
!Sub “${NetworkStackName}-RDSSubnet1aId”
（正しい構文2）
SubnetId: !ImportValue: !Sub “${NetworkStackName}-SubnetID”
2025-4-28
cloudformationにて、Type: AWS::RDS::DBClusterで定義可能なAuroraクラスターリソースに関して、PreferredBackupWindowプロパティとPreferredMaintenanceWindowプロパティ間で時刻が重複してはいけないことを知りました。
下記定義でデプロイしたところ、デプロイ自体は成功しましたが、22時で1分間被っていることに対して警告が発令されました。
PreferredBackupWindow: 22:00-23:00 # 日本時間 7:00~8:00
PreferredMaintenanceWindow: sat:21:00-sat:22:00 # 日本時間 毎週日曜6:00~7:00
2025-4-30
ALBからECSタスクへのリクエストのルーティングの流れを知ることができました
1. タスクに属する「コンテナとリッスンしているポート」の組み合わせに対して、ECSエージェントがタスク起動時に動的にポートを割り当てる
2. タスク（ホスト）が持つプライベートIPと1で付与された動的ポートの組み合わせを、ALBのターゲットグループにターゲットとして登録
3. ALBはリスナールールに基づき、適したターゲットグループ内のターゲット（タスクIPと１で付与された動的ポートの組み合わせ）にリクエストをルーティング
4. ECSはALBからのトラフィックを、動的ポートからタスク内の「コンテナとリッスンしているポート」の組み合わせを逆引きし、そこにリクエストをルーティング
これにより、１タスク内に複数コンテナまた複数ポートが存在する状況においても、ALBから適したコンテナのポートへリクエストをルーティングが可能になる