2024/07　CTOへの日報まとめ

日報




2024-7-1

ランサムウェアという攻撃について知ることができました。

・ランサムウェアとは、何らかの方法でシステムに侵入し、システム内のデータを暗号化することで、復旧と引き換えに身代金を要求する攻撃のこと

2024-7-2

SAML認証について知ることができました。

  • 前提として、SAML（Security Assertion Markup Language）とは、IdP（Identity Provider, 認証提供者）とSP（Service Provider, サービスプロバイダー）間で認証および認可データを交換するためのXMLベースの標準プロトコルのこと
  • そして、SAML認証とは、このSAMLというプロトコルを用いた認証のこと。主にSSOに利用される

基本的な概念

IdP（Identity Provider, 認証提供者）
ユーザーの認証情報を管理し、認証を行うサービス。例えば、GoogleやMicrosoft Azureなど。

SP（Service Provider, サービスプロバイダー）
認証情報を受け取り、ユーザーにサービスを提供するアプリケーションやシステム。例えば、SalesforceやSlackなど。

Assertion（アサーション）
IdPがユーザーの認証情報を含むデータをSPに送る際に使用するXML文書。ユーザーの識別情報や認証結果を含む。

認証フロー
1. ユーザーがSPにアクセス
ユーザーがサービスプロバイダーのリソースにアクセスしようとする

2. SPがIdPにリダイレクト
SPはユーザーを認証するためにIdPにリダイレクトし、認証要求（SAMLリクエスト）を送る

3. ユーザーがIdPで認証
ユーザーはIdPでログイン情報を入力し、認証を行う

4. IdPがアサーションを生成
認証が成功すると、IdPはユーザーの認証情報を含むSAMLアサーションを生成し、ユーザーをSPにリダイレクトする

5. SPがアサーションを検証
SPは受け取ったアサーションを検証し、ユーザーを認証する

6. ユーザーがサービスにアクセス
認証が成功すると、ユーザーはサービスプロバイダーのリソースにアクセスできるようになる

SSOを実現するために利用されることが多いみたく、それ以外の場面ではあまり使われない認証方式のようですが、1つ認証に関する知見が増えたので、良かったです。

2024-7-5

CPUのアーキテクチャである「AMD64」と「ARM64」について、その違いや特徴が分からなかったので調べてみました

AMD64（x86-64）

  • 特徴：64ビットのプロセッサアーキテクチャ（CPUの構成）で、x86アーキテクチャを拡張して64ビット処理能力を持たせたもの
  • 主な用途：パーソナルコンピュータ、サーバー、ワークステーションで広く使用されている。Windows、Linux、macOSなど、多くのオペレーティングシステムがこのアーキテクチャをサポートしている
  • 性能：高性能な処理が可能で、特に大規模なデータセンターや複雑なグラフィック処理、科学技術計算に適している

ARM64（AArch64）

  • 特徴：64ビットのプロセッサアーキテクチャで、元々の32ビットARMアーキテクチャの拡張版
  • 主な用途：スマートフォン、タブレット、組み込みシステムなど、省エネ性が重視されるデバイスに広く使用されている。近年では、サーバーやパーソナルコンピュータ（AppleのM1チップなど）での採用も増えている
  • 性能：高効率で省エネ性に優れているため、バッテリー駆動時間が長いモバイルデバイスに適している

比較

  • パフォーマンスと効率：AMD64は高性能を重視しているのに対し、ARM64は効率と省エネ性を重視している
  • 使用されるデバイス：AMD64は従来型のPCやサーバーで主に使用され、ARM64はモバイルデバイスや特定のサーバー、新型のPCで使用される
  • エコシステムと互換性：AMD64は広範なデスクトップアプリケーションと互換性があるが、ARM64はモバイルアプリや新しいデスクトップアプリケーションの開発で優位性を持っている

どちらのアーキテクチャも、現代のコンピューティングニーズに応じた独自の利点を持っており、用途や要件によって選択が異なる。

2024-7-8

安定したサービス運用に必要な「グレースフルシャットダウン」という手法について知ることができました。

  • グレースフルシャットダウンとは、コンピューターシステムやソフトウェアアプリケーションが使用中のリソースやプロセスを適切に閉じたり、保存したりすることによって、安全にシステムを停止するプロセスのこと
  • これは、データの損失を防ぎ、再起動時に問題が発生するのを防ぐために重要

例えば、Webサーバーやデータベースサーバーにおいてグレースフルシャットダウンを行う場合、次のようなステップが含まれる

1. 新しいリクエストの受付を停止する

2. 現在処理中のリクエストが完了するのを待つ

3. 全てのデータをディスクに保存し、オープンしているファイルやコネクションをクローズする

4. 必要に応じてユーザーに通知を行い、システムがシャットダウンしていることを伝える

5. システムの電源を切るか再起動を行う

このプロセスは、予期せずシステムが停止することによるデータの破損や不整合を避けるために役立つ。特に、データの整合性を保つことが重要なデータベースやファイルサーバーでは、グレースフルシャットダウンが非常に重要。

2024-7-9 ①

安定したサービス運用を実現するために行われるエクスポネンシャルバックオフについて知ることができました。

  • エクスポネンシャルバックオフ（Exponential Backoff）とは、ネットワークリクエストやAPIコールなどでの衝突や過負荷を防ぐためのアルゴリズム
  • この手法では、リクエストが失敗するたびにリトライまでの待機時間を指数関数的に増加させる。つまり、リトライの間隔が失敗の度に急速に長くなる

エクスポネンシャルバックオフの基本的なプロセス
1. 初期リトライインターバルの設定： 最初のリトライ待機時間（たとえば100ミリ秒）を設定する

2. リトライの実行： リクエストを再送信する。成功すればプロセスを終了する

3. 失敗時の処理： リクエストが再び失敗した場合、待機時間を指数関数的に増加させる（例えば、初期値の2倍、4倍、8倍…）

4. 最大リトライ回数の設定： リトライは無限に続けるわけではなく、最大リトライ回数や最大待機時間を設定しておくことが一般的

5. ジッターの追加： サーバーへのリクエストが一斉に再開されることを防ぐために、待機時間にランダムな時間（ジッター）を加えることがある。これにより、リクエストが同時にサーバーに到達することを防ぐ。

2024-7-9 ②

foreachの内側にswitchがあり、switchで何か特定の条件を満たした場合は、即座に次のforeachのループへと移りたい。ただし、breakで抜けるとswitchの後続で書かれている処理が走ってしまい、これは都合が悪い

このような状況のときには、continue 2;を使うことで、「switch」と「foreachの現在のループ」の２段階を抜けることができ、switchの後続の処理を動かすことなく、foreachの次のループへと移れることを知りました。

言葉で示すのは限界があると思い、サンプルプログラム書いてみました
https://paiza.io/projects/ca-qUmD6Khh7dVZLKwwG8g

（上記サンプルプログラムの出力は下記）
2
switchの外
switchの外
// echo “switchの外\n”; // case 1の場合、continue 2;により、これが動かない

2024-7-11

AWSアカウント毎に各AZが指す物理的なゾーンが異なる可能性があることを知りました。つまりAWSアカウント1が指す1-aというAZと、AWSアカウント2が指す1-cというAZが物理的には同じゾーンを指すという事象が発生する可能性があることを知りました。

自分でも少し調べてみましたが、下記の記事が非常に分かりやすかったです。
https://qiita.com/jun_inoue/items/7f5da4e2d669ad97c770

上記記事でも言及されていることではありますが、このようなAWSの仕様により、気をつけないといけない点が１つあると思いました。まあ、あまりないかもしれませんが、複数のAWSアカウントを跨いで1つのシステムを構築する際に、可用性の観点からAWSアカウント間で各リソースを異なるAZを分けて配置したとしても、実際には物理的に同じAZに配置されていて、結果可用性が担保されていないという事象が発生する可能性があるなと思いました。そこは気をつけないといけないと思いました。

ただ、とはいえ、これを防ぐために今ではAZ IDというものが存在するみたいです。1つ1つの物理的なゾーンに対してAZ IDという一意のidが割り当てられているみたいなので、これを使用してリソースの配置先AZを指定すれば、意図せず複数のAWSアカウント間で物理的には同じAZに配置されているという事象は防げるみたいです。

2024-7-12

AWSでコンテナ運用する際に出てくるECS、EKS、EC2、Fargateの各サービスに関して、それらの関係性がいまいち分かっていなかったので調べました。

前提として

  • ECSとは、AWSが提供するコンテナオーケストレーションツールのこと
  • EKSとは、OSSのコンテナオーケストレーションツールであるKubernetesをAWS上で動かすサービスのこと

ECS、EKSは下記2つの方法で動作させることができる

  • EC2上で利用（ECS on EC2）（EKS on EC2）
  • Fargate上で利用（ECS on Fargate）（EKS on Fargate）

EC2上で利用する場合

  • EC2にdockerを入れることで、コンテナ実行環境が出来上がる
  • 非常に自由度が高い。ただし、その分運用が難しい
  • コストはFargateに比べて安価

Fargate上で利用する場合

  • Fargateとは、サーバーレスなコンテナ実行環境
  • 基盤のインフラを気にする必要がなく、運用コストが下がる
  • しかし、コスト面ではEC2より高価であり、また自由度は低い

これより、利用するツールの選定には、下記の順序で考えることが妥当であることを知りました。

1. まずは、EC2にdockerを突っ込んでコンテナ化された仮想サーバーを立てるのか、あるいはFargateという既に用意されたコンテナ実行環境を使うのか検討する

2. その後、それらコンテナ実行環境を管理していく際には、「ECS」を使うのか、「EKS」を使うのか検討する

よく「ECS on EC2」や「EKS on Fargate」という用語を耳にしていましたが、果たしてそれがどのような状態を指しているのか分かっていなかったため、そこがクリアになり良かったです。

2024-7-16

AWS Lambdaに同時実行数の上限があることを知りました。

  • AWS Lambdaに同時実行数の上限がある
  • この上限はデフォルトでアカウント全体に対して設定されている
  • 2024年7月時点で、デフォルトの同時実行数の上限は1,000
  • もしデフォルトの上限を超える同時実行が必要な場合は、AWSサポートにリクエストを提出することで、この上限を引き上げることができる
2024-7-17

ゴールデンテスト（Golden Test）というテスト手法について知ることができました。

  • ゴールデンテストとは、ソフトウェアテストの一種で、特定の入力に対する期待される出力（ゴールデンマスター）と実際の出力を比較するテスト方法
  • このテスト手法は、特に回帰テストやソフトウェアのリファクタリング時に有用

ゴールデンテストの主なポイント

  • ゴールデンマスターの作成：初めに、特定の入力に対する期待される出力（ゴールデンマスター）を生成する。この出力は、正しい結果として保存される
  • テスト実行：同じ入力を用いてソフトウェアを実行し、得られる出力をゴールデンマスターと比較する
  • 比較と検証：実際の出力がゴールデンマスターと一致するかどうかを確認する。一致しない場合、ソフトウェアの変更が予期しない結果をもたらしている可能性がある
  • ゴールデンマスターの更新：ソフトウェアが意図的に変更され、期待される出力が変わった場合、新しい出力をゴールデンマスターとして更新する

ゴールデンテストの利点

  • 回帰バグの検出：既存の機能が変更されていないことを確認するのに役立つ
  • 変更の影響範囲の確認：ソフトウェアの変更が予期しない場所に影響を及ぼしていないかを確認できる
  • 簡単な実装：比較的簡単に実装でき、特に入出力が明確に定義されている場合に有効

ゴールデンテストの欠点

  • ゴールデンマスターの管理が大変：ソフトウェアの変更が頻繁に行われる場合、ゴールデンマスターの管理が手間になることがある
  • 大規模データセットの比較が難しい：出力が非常に大きい場合、微小な差異を検出するのが難しくなることがある

ゴールデンテストは、他のテスト手法と組み合わせて使用することで、ソフトウェアの品質を高める有力な手段となる

2024-7-18

EC2のインスタンスタイプ「t2およびt3系」におけるベースライン性能とバースト能力について知ることができました。

ベースライン性能

  • t2およびt3インスタンスには「ベースライン」という、定義されたCPU性能の割合がある
  • 例えば、t2.microの場合、ベースラインは10%
  • これは、常に使えるCPU性能の基準を示す

CPUクレジット

  • インスタンスがベースライン以下で動作している間、CPUクレジットが貯まる
  • CPUクレジットは、後でバーストするために使用できる
  • 各インスタンスタイプには、貯められるクレジットの上限があり、これを超えるとクレジットはそれ以上貯まらない

バースト機能

  • 必要な場合、貯めたCPUクレジットを使用して、ベースラインを超えたCPU性能を一時的に利用できる
  • アクセスが集中し、必要なCPUがベースラインを超えた際にバーストモードに切り替わる
  • クレジットが尽きると、CPU使用率は再びベースラインに戻る

この仕組みにより、通常の低負荷の処理を行いながら、必要なときに高負荷の処理も可能となる。これはコスト効率の良い運用を目指す場合に有効。

2024-7-19

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

  • OPCacheとは、PHPのオペコードキャッシュシステムのこと
  • オペコードキャッシュとは、PHPスクリプトをコンパイルした後の中間コード（オペコード）をキャッシュすることで、スクリプトの実行を高速化する仕組みのこと
  • 通常、PHPスクリプトはリクエストごとにパースおよびコンパイルされるため、サーバーの負荷が増加する
  • OPCacheはこのコンパイルステップを省略し、既にコンパイルされたオペコードをメモリにキャッシュすることで、パフォーマンスを向上させる

主な特徴と利点

  • パフォーマンス向上：キャッシュされたオペコードを再利用することで、スクリプトの実行時間が短縮される
  • メモリ効率：複数のPHPプロセス間でオペコードを共有することで、メモリの使用効率が向上する
  • 設定が簡単：php.iniファイルにいくつかの設定を追加するだけで簡単に有効化できる
2024-7-23

Postfixについて知ることができました

  • Postfixとは、オープンソースのメールトランスファーエージェント（MTA）
  • 主にUNIXベースのシステムで使用される
  • Postfixは、電子メールの送信、受信、転送の役割を担うプログラムで、セキュリティ、パフォーマンス、シンプルさを重視して設計されている

主な機能と特徴

セキュリティ

  • Postfixは多層防御アーキテクチャを採用しており、セキュリティリスクを最小限に抑える設計がなされている
  • デフォルトで最小権限の原則に従う設定が施されており、不必要な特権を持たないようにしている

パフォーマンス

  • 高いパフォーマンスを提供し、大量のメールトラフィックを処理できる
  • 高速なメール配送を実現するために、メールキューの管理が効率的に行われる

シンプルさと拡張性

  • 設定ファイルが比較的シンプルで理解しやすく、管理が容易
  • モジュール式の設計により、必要な機能を簡単に追加・拡張できる

互換性

  • 他のメールシステムとの互換性が高く、容易に移行や統合が可能
2024-7-24

Cronについて知ることができました

  • Cronとは、Unix系OSでタスクをスケジュールするためのデーモン
  • 定期的なタスクを自動的に実行するために使用される

Cronの基本的な使い方と設定方法

Cronの基本構造

  • Cronジョブは、crontab（cron table）ファイルに記述される
  • 各ユーザーは独自のcrontabを持つことができる
  • crontabファイルには、実行するコマンドとその実行スケジュールが記述されている

Crontabの編集

  • ユーザーのcrontabファイルを編集するには、crontab -e コマンドを使用する
  • これにより、crontabエディタが開き、ジョブを追加・編集することができる

Crontabファイルの書式
Crontabファイルの各行は、以下の形式で記述される
* * * * * コマンド
分 時 日 月 曜日 コマンド

各フィールドの意味は以下の通り
分（0 – 59）
時（0 – 23）
日（1 – 31）
月（1 – 12）
曜日（0 – 7）（0と7は日曜日）

例えば、毎日午前3時15分にスクリプトを実行するには、以下のように記述する
15 3 * * * /path/to/script.sh

特殊な時間指定
以下のような特殊な時間指定も使用できる

  • @reboot：システムが起動したとき
  • @yearly または @annually：毎年
  • @monthly：毎月
  • @weekly：毎週
  • @daily または @midnight：毎日
  • @hourly：毎時

例えば、システムが再起動したときにスクリプトを実行するには、以下のように記述する

  • @reboot /path/to/script.sh

Cronジョブの確認
現在のユーザーのcrontabを表示するには、以下のコマンドを使用する
crontab -l

Cronのログ

  • Cronジョブの実行結果やエラーは、通常、システムログに記録される
  • ログファイルはシステムによって異なるが、一般的には /var/log/cron, /var/log/syslog にある

サンプルCrontabエントリー
毎週月曜日の午前1時にバックアップスクリプトを実行する場合
0 1 * * 1 /path/to/backup.sh

Unix系OSにこのようなデーモンが搭載されていることを知れて良かったです

2024-7-25

PHPのPDO（PHP Data Objects）について知ることができました。

  • PDOとは、データベースアクセスのための軽量で一貫性のあるインターフェースを提供する拡張機能
  • PDOは、異なるDBMSに対する抽象化レイヤーを提供し、SQL文のプレースホルダーのサポートなどの安全なデータベース操作を促進する

主な特徴
1. 統一されたインターフェース

  • PDOは、多くの異なるDB（MySQL, PostgreSQL, SQLite, SQL Serverなど）に対して同じAPIを提供する
  • これにより、データベースを変更する場合でもコードの変更を最小限に抑えることができる

2. プリペアドステートメント

  • プリペアドステートメントは、SQLインジェクション攻撃を防ぐための強力な方法
  • クエリを実行する前にクエリを準備し、実行時にパラメータをバインドすることで、安全かつ効率的なデータベース操作を実現する

3. トランザクションのサポート

  • PDOは、トランザクションの開始、コミット、ロールバックをサポートしている

PDOを使用することで、安全かつ効率的にデータベースにアクセスすることができる。特に、SQLインジェクションの防止と異なるデータベース間での移植性の向上に大きなメリットがある。

2024-7-26

docker-composeでデータストアを構築する際に、volumesによりコンテナのライフサイクルとは独立したデータ管理が行われ、データの永続化が図られると思います。

例えば、docker-composeでRedisを構築する際は、下記のような記述により構築が実現されます。

services:
todo-redis:
image: "redis:latest"
container_name: todo_redis
port:
- "36379:6379"
volumes:
- todo-redis-data:/data
volumes:
todo-redis-data:

このときに、volumesで管理されているデータ（todo-redis-data）が、実際にホストマシン上のどのディレクトリに格納されているのか気になったので、それを特定する方法を探しました。下記のコマンドにより特定可能であることを知りました。

docker volume inspect todo-redis-data

このコマンドを実行すると、ボリュームの詳細情報がJSON形式で表示される。そして、その中にMountpointという項目があり、このパスにデータが保存されている。

出力例
[
{
"CreatedAt": "2024-07-26T12:34:56Z",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/todo-redis-data/_data",
"Name": "todo-redis-data",
"Options": {},
"Scope": "local"
}
]

上記出力の場合、/var/lib/docker/volumesに、todo-redis-dataというディレクトリが作成され、その中にデータが保存されている

2024-7-29

JWTの構成について、下記記事で理解を深めることができました
https://qiita.com/Hirohana/items/aa8651a520cdbbb68046

2024-7-30

.htaccessについて、下記の記事で理解を深めることができました。
https://qiita.com/sanogemaru/items/7e5bd6e8dc9b04c9978e

これまでは、.htaccess = 「Webサーバーの設定をディレクトリ単位で行うための設定ファイル」という理解だけで、具体的にどのような制御ができるのか理解できていませんでしたが、上記の記事などを通して、具体的にどのような制御ができるのか知ることができました。

2024-7-31

GitHub Actionsのサービスコンテナについて知ることができました。

  • GitHub Actionsのサービスコンテナとは、ワークフローの一部として使用されるサポートコンテナのこと
  • サービスコンテナは、主なジョブの実行環境とは別に、データベースやキャッシュサーバーなど、依存関係として必要なサービスを提供するために使用されるコンテナ

（例）
on:
push:
branches:
- "main"
pull_request:
name: test
jobs:
test:
runs-on: ubuntu-latest
services:
mysql:
image: mysql:8.0.29
options: >-
--health-cmd "mysqladmin ping -h localhost"
--health-interval 20s
--health-timeout 10s
--health-retries 10
ports:
- 3306:3306
env:
MYSQL_ALLOW_EMPTY_PASSWORD: yes
MYSQL_DATABASE: hoge
MYSQL_USER: hoge
MYSQL_PASSWORD: hoge
steps:
（以下、ワークフロー定義）

GitHub Actionsワークフロー実行環境にて、ワークフローで使用するコンテナを立てることができることを知りました