2024/09　CTOへの日報まとめ

日報




2024-9-2

composer.json と composer.lockの用途や違いについて、定期的に忘れてしまうので、改めて調べてみました

composer.json と composer.lock は、ComposerベースのPHPプロジェクトで重要な役割を果たす2つのファイル

composer.json

  • このファイルは、プロジェクトの依存関係を宣言するためのファイル
  • プロジェクトが必要とするパッケージやそのバージョン情報が記載されている
  • また、プロジェクトのメタデータ（プロジェクト名、バージョン、ライセンスなど）や、スクリプト、オートロード設定なども定義できる

{
“require”: {
“laravel/framework”: “^8.0”,
“guzzlehttp/guzzle”: “^7.0”
},
“autoload”: {
“psr-4”: {
“App\\”: “app/”
}
}
}

上記の例では、laravel/frameworkとguzzlehttp/guzzleが依存パッケージとして指定されている。開発者がプロジェクトに新しい依存パッケージを追加したい場合は、composer requireコマンドを使用してこのファイルを更新する。

composer.lock

  • このファイルは、プロジェクトにインストールされた全ての依存パッケージの正確なバージョンを記録する
  • composer installが実行されるときに使用され、すべての開発環境で同じバージョンのパッケージがインストールされることを保証する

{
“name”: “laravel/framework”,
“version”: “8.40.0”,
“source”: {
“type”: “git”,
“url”: “https://github.com/laravel/framework.git”,
“reference”: “abcd1234…”
},
“require”: {
“php”: “^7.3|^8.0”,
“illuminate/contracts”: “^8.0”,
// さらに多くのパッケージ…
},
// 他の依存パッケージの詳細も記録される
}

この例では、laravel/frameworkの正確なバージョンと、依存関係の詳細が記録されている。composer.lockが存在するプロジェクトでcomposer installを実行すると、このファイルに基づいて正確なバージョンのパッケージがインストールされる。これにより、チーム全体や異なる環境間で依存関係の一貫性が保たれます。

違い

  • composer.jsonは、プロジェクトで必要な依存パッケージの大まかなバージョンや設定を定義するファイル
  • composer.lockは、インストールされた依存パッケージの正確なバージョンを記録し、環境間で同じバージョンを再現するためのファイル

簡潔にまとめると、composer.jsonは「何が必要か」を記述し、composer.lockは「実際にインストールされたもの」を記録する役割を持っている

2024-9-4

composerを使用して依存関係を管理しているプロジェクトを本番環境にデプロイする際に、composer install –no-dev を使用することで、本番環境に不要な開発用パッケージをインストールせずに済むことを知りました。

composer install –no-dev コマンドは、require-dev セクションに定義されたパッケージをインストールしないように指示するもの

開発時のみ使用するパッケージとは、どういったものか

1. デバッグツール
例：phpunit/phpunit（テストフレームワーク）、symfony/var-dumper（変数のデバッグ表示を行うツール）

2. 静的解析ツール
例：phpstan/phpstan（静的コード解析ツール）、friendsofphp/php-cs-fixer（PHPコードのスタイルを修正するツール）

3. テストフレームワーク
例：phpunit/phpunit（テストの実行）

4. 開発支援ツール
例：fzaninotto/faker（テストデータの生成）、nunomaduro/collision（CLIでのエラーハンドリング）

どのようにして開発時のみ使用すると判定するのか
→ Composerは、composer.jsonファイルに、require セクションと require-dev セクションの二つを持っている

  • requireセクション：ここにリストされたパッケージは、本番環境でも必要な依存関係。例えば、フレームワーク本体や、データベース接続に必要なライブラリなどが含まれる
  • require-devセクション：ここにリストされたパッケージは、開発時にのみ必要な依存関係。これらのパッケージは本番環境では不要で、開発、デバッグ、テストなどに使用される

composer install –no-dev を実行すると、require セクションに記載されたパッケージのみがインストールされ、require-dev セクションに記載された開発用パッケージはインストールされない

判定基準

  • 開発時のみ使用するかどうかは、プロジェクトの要件や目的に応じて判断される
  • 例えば、あるパッケージが本番環境で動作するために必須であれば require に、開発中のみ必要で本番では不要であれば require-dev に配置される
  • 具体的には、composer require コマンドでインストールする際に、–dev オプションを使うとそのパッケージは require-dev に追加される（composer require –dev phpunit/phpunit）

このようにして、パッケージが開発時のみ必要なものかどうかを明確に区別することができる

2024-9-5

VPCのルートテーブルがどのようなものか完全に忘れてしまったため、改めて調べました。下記の記事が分かりやすく、理解を深めることができました。
https://en-junior.com/routetable/

2024-9-6

CloudWatchのVended Logsについて知ることができました。

CloudWatchのVended Logsとは、AWSの特定のサービスが自動的にCloudWatch Logsに送信するログのこと。これらのログは、ユーザーが手動で設定しなくても自動的に配信され、AWSリソースの監視を簡単に行うことができる。例えば、Lambdaのログをcloudwatchに送信するには、そもそもはじめにLambdaがログを吐くように設定する必要がある。しかし、Vended Logsの場合、開発者が特別な設定をしなくても、自動的にログが収集される。Vended Logsの例としては、VPC Flow LogsやRoute53 Resolverのログなどが該当する。Vended Logsは通常、他のログと比べて料金が安く設定されている。たとえば、VPC Flow Logsは通常のログの半額程度のコストで保存できる。

2024-9-9 ①

SQLiteがどのようなDBなのか知ることができました。

  • SQLiteは、軽量で組み込み型のRDBMS
  • 他の一般的なRDBMS（MySQL、PostgreSQLなど）と異なり、クライアント・サーバーモデルではなく、ライブラリとしてアプリケーションに直接組み込んで使用することができる

特徴

  • 軽量でコンパクト：SQLiteのDBエンジンは非常に小さく、数メガバイト程度のディスクスペースしか必要としない。インストールも不要で、単一のファイルとして運用できる
  • 自己完結型：SQLiteは一つのファイルにすべてのデータベース情報（データ、スキーマ、インデックスなど）を格納する。そのため、データベースの移動やバックアップが容易
  • ACID準拠：SQLiteは、Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）を保証しており、トランザクション管理が可能
  • サーバーレス：SQLiteはサーバーとして動作しないため、複雑なサーバーのセットアップが不要。アプリケーションに直接データベース機能を組み込むことができ、シンプルなデプロイが可能
  • マルチプラットフォーム：Windows、macOS、Linuxなど、様々なプラットフォームで利用可能
  • オープンソース：SQLiteはオープンソースで、パブリックドメインとして提供されている。そのため、商用利用も無料で可能

利点

  • セットアップが簡単：特別な設定やサーバーの構築が不要で、ライブラリをリンクするだけですぐに使えるため、開発初期のプロトタイピングや小規模なアプリケーションに適している
  • 持ち運びが容易：単一ファイル形式であるため、データベースを簡単にコピーしたり、別の環境に移動させたりできる
  • パフォーマンス：小規模データベースにおいては、非常に高速でパフォーマンスが良い

欠点

  • 並列処理が制限される：サーバーレスであるため、複数のクライアントからの同時アクセスには向いていない。特に書き込み時に同時アクセスが発生するとパフォーマンスが低下する
  • 大規模データには不向き：非常に大規模なデータベースや高度な並列処理が必要なシステムには、MySQLやPostgreSQLのようなサーバーベースのデータベースの方が適している

使用例

  • モバイルアプリ：iOSやAndroidアプリのローカルデータベースとして広く利用されている
  • 組み込みシステム：家電製品やIoTデバイスなど、リソースが限られた環境でのデータ管理に適している
  • 小規模ウェブサイト：小規模なブログやポートフォリオサイトなど、トラフィックが少ない場合に利用される

SQLiteは、シンプルかつパワフルで、特に小規模なアプリケーションや一時的なデータベースニーズに最適

RDBMSは、MySQLとMariaDBしか使用経験がないため、将来的には他のRDBMSも経験してみたいなと思いました

2024-9-9 ②

step functionsの Fail ステートについて知ることができました

  • Fail ステートとは、そのステートマシン、あるいは Map ステート内の特定のイテレーションを失敗させるために使用される
  • Fail ステートには “End”: true を設定する必要はない
  • Fail ステート自体、ステートマシンの実行を終了させるためのものであり、そのステートが呼び出された時点でエラー情報が返され、そのイテレーションは失敗として扱われる
  • Map ステート内で Fail ステートに達した場合、そのイテレーションは失敗として扱われるが、他のイテレーションは独立して処理を続ける
  • Map ステート全体の挙動としては、エラーハンドリング（Catch など）がどのように設定されているかに依存する
  • もし Catch が設定されていなければ、一つのイテレーションの失敗が Map ステート全体の失敗を意味する場合がある
2024-9-10 ①

DBの複合インデックスについて知ることができました。

  • DBの複合インデックスとは、DBのインデックスの一種で、複数のカラムを一つのインデックスとして結合したもの
  • これにより、複数のカラムを基にした検索を効率化することができる

主なポイント

1. 複数カラムを結合してインデックスを作成

  • 例えば、usersテーブルに first_name と last_name のカラムがある場合、これら二つを組み合わせて一つの複合インデックスを作成することが可能　CREATE INDEX idx_name ON users (first_name, last_name);

2. インデックスの優先順位

  • 複合インデックスには順序があり、検索クエリの最適化に影響を与える
  • 例えば、上記のインデックス idx_name は first_name → last_name の順で構築されるため、first_name を指定した検索クエリは最適化されるが、last_name だけを指定したクエリは必ずしも最適化されない
  • このように、複合インデックスはクエリの構造によって効果的に利用されるかどうかが決まる

3. 検索条件での利用

  • 複合インデックスは、最初のカラムまたはその後の複数のカラムを含むクエリで効率的に利用できる
  • 例えば、WHERE first_name = ‘John’ AND last_name = ‘Doe’ のようなクエリはインデックスがフルに活用されるが、WHERE last_name = ‘Doe’ だけではインデックスが使用されないか、部分的にしか活用されない

4. データベースエンジンに依存する動作

  • 使用しているデータベースエンジン（例: MySQL、PostgreSQL、Oracleなど）によって、インデックスの動作や最適化の方法が異なる場合がある

5. パフォーマンス向上

  • 適切に複合インデックスを作成することで、特定のクエリのパフォーマンスが大幅に向上する
  • ただし、インデックスが増えすぎると、データの挿入や更新時のパフォーマンスに悪影響を与えるため、適切なバランスが必要

複数のカラムのペアで１つのインデックスを構築できることは知らなかったので、新たな知見を得ることができました

2024-9-10 ②

cloudformationテンプレートにて、Type: AWS::Serverless::StateMachine で定義するstep functionsリソースの定義において、追加でLoggingを定義することでワークフローで発生したログの送信先を指定できることを知りました

2024-9-11

cloudformationテンプレートにて、Type: “AWS::Logs::MetricFilter” により定義したメトリックフィルターリソース定義にて、LogGroupName に対象のロググループのリソース定義名を指定した場合、その時点でCloudFormationはロググループとメトリックフィルター間の依存関係を自動的に認識するため、DependsOn の指定は不要であること。それに対して、LogGroupName にリソース定義名ではなく、直接ロググループの名前を指定した場合は、CloudFormationはそれらリソース間の依存関係を認識できないため、メトリックフィルターのDependsOn にて、明示的に依存するロググループを指定する必要があることを知りました。

2024-9-12

EC2インスタンス起動時に設定するキーペアに関して、これまでは「同じキーペアを複数のインスタンスで使い回すこと」はよくないことなのかなと思っていましたが、調べてみるとそれはよくあることであり、悪いことではないことを知りました。インスタンス毎にキーペアを分けることで、管理が煩雑になり、かえってセキュリティリスクが増加する可能性もあるなと思いました

2024-9-13

cloudformationテンプレートにて、Type: “AWS::CloudWatch::Alarm” により定義するCloudWatchアラームについて、下記３つのプロパティが意味する設定について理解することができました。

  • Period：データを集計する時間の長さ。例えば、Period を 60 に設定した場合、CloudWatchは毎分データを集計する
  • EvaluationPeriods：アラームが評価する集計データポイントの数。例えば、1 に設定されている場合、直近の集計期間のデータポイントのみを考慮する
  • DatapointsToAlarm：アラームをトリガするために必要な閾値を超えたデータポイントの最小数。例えば、1 に設定されていれば、評価期間中に1回閾値を超えればアラームがトリガされる
2024-9-17

AWS Systems Manager（SSM）について知ることができました。

  • AWS Systems Manager（SSM）とは、AWS インフラストラクチャの管理を簡素化するために設計された統合ツールセット
  • SSM を使用すると、クラウドやオンプレミスのサーバー、仮想マシン、その他のリソースを効率的に管理、監視、制御することができる

主な機能

1. SSM パラメータストア（Parameter Store）

  • 機能：機密情報（API キー、パスワードなど）や設定データを保存および管理するための安全なデータストア
  • ユースケース：アプリケーションでの設定や機密情報の安全な管理や共有

2. SSM ドキュメント（Run Command）

  • 機能：EC2 インスタンスやオンプレミスのサーバーに対して、コマンドをリモートで実行するための機能
  • ユースケース：大規模な環境でパッチの適用、ソフトウェアのインストール、スクリプトの実行などを一括で行う

3. パッチマネージャ（Patch Manager）

  • 機能：EC2 インスタンスやオンプレミスのシステムに対するパッチ管理の自動化
  • ユースケース：OS の脆弱性修正やセキュリティパッチの自動適用

4. オートメーション（Automation）

  • 機能：EC2 インスタンスの管理作業（起動、停止、バックアップなど）を自動化するための機能
  • ユースケース：リソースの自動スケーリングや、日常的なメンテナンス作業をスケジュール設定して自動実行

5. インベントリ（Inventory）

  • 機能：EC2 インスタンスやオンプレミスのサーバーから、インストールされているソフトウェアや構成情報を収集して可視化
  • ユースケース：IT 資産管理やセキュリティ監査

6. セッションマネージャ（Session Manager）

  • 機能：SSH や RDP のようなリモート接続を必要とせず、ブラウザや AWS CLI を使用して EC2 インスタンスにセキュアにアクセス可能
  • ユースケース：SSH キー管理の不要化や、ネットワーク制限下での EC2 インスタンスの安全な管理

7. ステートマネージャ（State Manager）

  • 機能：EC2 インスタンスの構成や状態を管理し、特定のポリシーや構成が継続的に適用されるようにする
  • ユースケース：セキュリティポリシーの強制適用や構成のドリフト防止

SSM は、AWS 環境のセキュリティや運用効率を向上させ、複雑なシステム管理を自動化するための強力なツールとなっている

2024-9-19

データベースにおけるCascadeについて知ることができました。

データベースにおけるCascadeとは、外部キー制約に関連する動作の一つで、親テーブルのデータが変更（更新または削除）された際に、関連する子テーブルのデータも自動的に変更する仕組みのこと

カスケードの種類

１、ON DELETE CASCADE

  • 親テーブルの行が削除されたとき、外部キーで参照されている子テーブルの関連する行も自動的に削除される
  • これにより、参照整合性を維持しながら、手動で子テーブルのデータを削除する手間を省くことができる

例：下記の場合、departments テーブルの行が削除されると、department_id にてその削除された行を参照している employees テーブルの行も削除される

CREATE TABLE employees (
id INT PRIMARY KEY,
department_id INT,
FOREIGN KEY (department_id) REFERENCES departments(id) ON DELETE CASCADE
);

２、ON UPDATE CASCADE

  • 親テーブルのデータが更新されたとき、それを参照している子テーブルの外部キーも自動的に更新される
  • これにより、参照するデータが一致し続けることを保証できる

例：下記の場合、親となる departments テーブルの id が更新されると、それを参照している employees テーブルの department_id も自動的に変更される（親テーブルのidが変わることは基本ないかと思いますが、、、）

CREATE TABLE employees (
id INT PRIMARY KEY,
department_id INT,
FOREIGN KEY (department_id) REFERENCES departments(id) ON UPDATE CASCADE
);

カスケードの利点

  • 参照整合性の維持：親テーブルと子テーブル間のデータの整合性を自動的に保つことができ、手動でのデータ管理の負担が軽減される
  • データの自動管理：親データの削除や更新に対する対応が自動化されるため、プログラム側で手動の管理が不要になる

カスケードの注意点

  • 意図しない削除や更新：カスケードの設定を間違えると、意図しないデータが大量に削除または更新される可能性がある。そのため、どの場面でカスケードを適用するかは慎重に設計する必要がある

カスケード機能を適切に活用することで、外部キーの参照整合性を効率的に維持でき、データベース操作が簡便になる

2024-9-20

.zshrc の再読み込みを行うコマンドを知ることができました
$ source ~/.zshrc

zshの設定ファイル .zshrc に変更を加えた際には、その変更を反映させるために設定ファイルを再読み込みする必要がある（あるいはzshを再起動する）

2024-9-24

PHPのend関数とkey関数について知ることができました

end：配列の内部ポインタを最終要素にセットする
key：配列の内部ポインタが現在指している要素のキーを返す

2024-9-27

API1では、1回のユーザー取得リクエストで取得できるユーザー数の上限が1000のようですが、レスポンスにはhasNextというプロパティが用意されていて、これにより未取得のユーザーがいるか（1000名以上のときに機能する、ページネーションとしての役割を果たす）知ることができるとのことでした。これは非常に良い仕様だなと感じまして、今後自分がAPIを開発する立場にたち、返すデータ量に上限を設ける場合は「取得対象は上限以上に存在すること」を知らせる情報をレスポンスの一部として返すことで、API利用者フレンドリーなものを開発したいなと思いました

2024-9-30 ①

cloudformationテンプレートにて、Type: “AWS::Logs::MetricFilter” により定義するCloudWatchメトリックフィルターに関して、下記３つのプロパティが意味する定義について理解することができました。

前提として、AWS CloudWatch のメトリックフィルターとは、指定されたロググループに投稿されたログデータの中から、設定されたフィルターパターンに一致するログデータを抽出し、それに基づいてメトリクスを作成する機能のこと。これにより、ログデータから特定の情報を効率的にモニタリングし、アラートを設定することが可能になる。

  • MetricName：CloudWatchメトリックの名前を定義する
  • MetricNamespace：メトリックスをグループ化するための名前空間を指定する
  • MetricValue：メトリックの値を定義する。”1″を定義した場合、フィルターに一致するログが見つかるたびに、”1″ という値がメトリックとして記録される。この値はカウントとして利用され、例えば特定のエラーが発生した回数をカウントする際に使用されることがある

MetricValueがカウンターとして機能することを知りました。

2024-9-30 ②

下記のようなコードがあった際に、エディタの静的解析ツールが$this->appを認識できず、結果「isProductionというメソッドが定義されていない」というエラーを出すケースがあります。

Model::shouldBeStrict(!$this->app->isProduction());

そのような場合には、下記のように@var アノテーションを利用することで、静的解析ツールに「Illuminate\Foundation\Applicationで定義されているisProductionメソッド」であることを認識でさせることができ、余計なエラーを表示させないようにすることができることを知りました

use Illuminate\Foundation\Application;
public function boot() {
/** @var Application $app */
$app = $this->app;
Model::shouldBeStrict(!$app->isProduction());
}

@var アノテーションは、PHPの標準的な PHPDoc コメントの一部とのことで、知見を深めることができました。