カテゴリ

サーバー

LinuxやWebサーバー、デプロイ、保守まわりで手を動かした記録をまとめます。

まず押さえたいこと

サーバーは構築して終わりではなく、更新、バックアップ、監視、ログ、障害時の復旧まで含めて運用を考えます。

よくある入口

Linux初期設定、Webサーバー、メール送信、VPS、バックアップ、デプロイの記事を順に読むと全体像がつかみやすいです。

実務で見るポイント

設定値そのものより、なぜその設定にしたのか、障害時にどこを見ればよいのかを残しておくと後で助かります。

AWS WAF 入門 — CloudFront / ALB / API Gateway 連携と料金

AWS WAF は CloudFront / ALB / API Gateway / AppSync の前段で動く Web Application Firewall。SQL インジェクションや XSS を含む OWASP Top 10 系の攻撃、レート制限、Bot 対策、地理ブロックをマネージドルールで一括導入できます。仕組み、料金、ハマりやすい設定、「いつ入れるべきか」 を整理。

RDS vs Aurora vs Aurora Serverless v2 の選び分け

AWS で関係 DB を立てるとき、RDS / Aurora / Aurora Serverless v2 の 3 つから選ぶことになります。料金体系・スケール特性・運用負荷・対応エンジンが微妙に違い、`常時負荷の高さ』 『 スケール頻度』 『 コスト感』 で選び分けが必要です。3 者の仕組み、料金構造、典型用途を実務目線で整理します。

Terraform で AWS 最小構成を組む — State 管理から本番運用まで

Terraform は クラウドインフラをコードで管理する事実上の標準。AWS で本番運用を始めるとき、「S3 + DynamoDB の State 管理」 『 モジュール設計』 『 環境分離(dev / stg / prod)』 『 CI/CD と OIDC 連携』 を最初から正しく組むと、「後から散らかった構成を直す手間」 が圧倒的に減ります。最小構成の組み立て方を実務目線で整理します。

LLM アプリの観測性 — トークン・コスト・ハルシネーションを計測する

LLM アプリの観測性は 普通の Web アプリの観測性 + LLM 固有のメトリクス が必要です。トークン消費・コスト・レイテンシ・ハルシネーション率・ユーザー評価を OpenTelemetry ベースで計測し、改善のフィードバックループを回す設計を整理します。

コンテナ vs サーバレス vs VM — クラウド計算リソースの選び分け

クラウドで 「アプリをどこで動かすか」 の選択肢は VM(EC2)・コンテナ(ECS/EKS/Fargate)・サーバレス(Lambda) の3軸。「料金」 『 スケール特性』 『 運用負荷』 『 移植性』 で得意分野が違うので、「書きたいアプリの形」 と 「運用できる体制」 で選ぶのが基本です。3 つの違いと判断軸を整理します。

OpenTelemetry とは?トレース・メトリクス・ログを統一する観測性の標準

OpenTelemetry (OTel) は トレース・メトリクス・ログ を統一して扱う観測性(Observability)の業界標準。「SDK でアプリに計装 → Collector で集約 → 任意のバックエンド(Datadog / New Relic / Grafana / Jaeger / X-Ray)に送る」 のが基本構造。ベンダーロックインを避けつつ観測性を入れたい現代の開発で必須の技術を整理します。

レートリミットの代表アルゴリズム 4 つを比較 — Token Bucket / Leaky / Fixed / Sliding

レートリミット の代表アルゴリズムは Token Bucket / Leaky Bucket / Fixed Window / Sliding Window の 4 つ。「バーストを許すか」 『 公平性をどう取るか』 『 実装難度』 『 分散環境での同期コスト』 がそれぞれ違うので、「守りたい性質」 に合わせて選ぶ必要があります。アルゴリズムの仕組みと使い分けを実務目線で整理します。

Cloudflare Workers と CloudFront Functions / Lambda@Edge の違い

エッジで動くコードの選択肢として Cloudflare Workers、CloudFront Functions、Lambda@Edge があります。「どこで動くか」 『どの言語が使えるか』 『どこまで処理できるか』 『料金』 がそれぞれ違うので、「書きたい処理の重さ」 と 「料金感」 で素直に選び分けるのがコツです。仕組みと判断軸を整理します。

AWS IAM ロール / ポリシー / 権限境界 / SCP の使い分け

AWS IAM の ロール / アイデンティティポリシー / リソースポリシー / 権限境界 / SCP / セッションポリシー は、「似ているのに役割が違う」 ので混乱しやすい仕組みです。「どの階層で何を制御するか」 と 「評価ロジック(AND で絞り込み)」 を理解すれば、「必要なところまでだけ権限を絞る」 設計が組めます。実務目線で使い分けを整理します。