0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

メモ システム設計で必要な用語・概念まとめ

Posted at

システム設計で必要な用語・概念まとめ

はじめに

システム設計やプロダクト設計を行う際、エンジニアは多くの専門用語や設計パターン、アーキテクチャの知識が求められます。
本記事では「システム設計の面接試験 | アレックス・シュウ著」を参考に、設計時に知っておくべき用語やその使いどころをメモしました。


1. データベース関連

ACID特性

  • Atomicity(原子性)
    トランザクション内のすべての処理が「全て成功」または「全て失敗」になる性質。
    例:銀行振込で、送金元の口座から引き落としと送金先への入金が両方成功しなければならない。

  • Consistency(一貫性)
    トランザクション実行前後でデータの整合性が保たれること。
    例:外部キー制約やユニーク制約が常に守られる。

  • Isolation(独立性)
    複数のトランザクションが同時に実行されても互いに干渉しないこと。
    例:同じ商品を同時に購入しようとした場合、在庫数が正しく管理される。

  • Durability(永続性)
    コミットされたトランザクションの結果は、システム障害が発生しても失われないこと。
    例:電源断後もデータが消えない。

どんな時に必要か

  • 金融システムやECサイトなど、データの正確性・信頼性が求められる場面。

シャーディング(Sharding)

  • 意味
    データベースのデータを「水平方向(行単位)」で分割し、複数のDBサーバーに分散して保存する手法。


  • ユーザーIDの範囲ごとにDBを分ける(例:ID 1〜100万はDB1、100万1〜200万はDB2)

どんな時に必要か

  • データ量やトラフィックが膨大で、1台のDBサーバーでは処理しきれない場合。
  • SNSや大規模ECサイトなど。

レプリケーション

  • 意味
    データベースの内容をリアルタイムまたは定期的に他のサーバーに複製する仕組み。

  • 種類

    • マスタースレーブ(主従)型
    • マルチマスター型

どんな時に必要か

  • 可用性向上(障害時の切り替え)
  • 読み取り負荷分散(スレーブでSELECTのみ受ける)

インデックス

  • 意味
    検索を高速化するためのデータ構造(B+TreeやHashなど)。

  • 注意点
    インデックスを増やしすぎると、INSERT/UPDATEのパフォーマンスが低下する。

どんな時に必要か

  • 検索クエリのパフォーマンス改善が必要な場合。

キャッシュ

  • 意味
    頻繁にアクセスされるデータを一時的に保存し、DBへのアクセス回数を減らす仕組み。

  • 種類

    • メモリキャッシュ(例:Redis, Memcached)
    • アプリケーションキャッシュ

どんな時に必要か

  • DB負荷軽減、レスポンス高速化が必要な場合。

2. スケーラビリティ・パフォーマンス

レートリミット(Rate Limiting)

  • 意味
    一定時間内のリクエスト数を制限する仕組み。
    例:1分間に100回以上のAPIリクエストを拒否する。

  • 実装例

    • トークンバケット方式
    • リーキー・バケット方式

どんな時に必要か

  • APIの乱用防止
  • サービスの安定運用
  • DDoS攻撃対策

ロードバランサー

  • 意味
    複数のサーバーにリクエストを分散する装置・仕組み。

  • 種類

    • L4ロードバランサー(IP/ポート単位)
    • L7ロードバランサー(HTTPヘッダやURL単位)

どんな時に必要か

  • 高トラフィック対応
  • サーバー障害時の冗長化

CDN(Content Delivery Network)

  • 意味
    静的コンテンツ(画像・動画・JS/CSS等)を地理的に分散したサーバーから配信する仕組み。

どんな時に必要か

  • グローバルなレスポンス高速化
  • オリジンサーバーの負荷軽減

スケールアップ/スケールアウト

  • スケールアップ
    1台のサーバーのCPUやメモリなどの性能を上げる

  • スケールアウト
    サーバー台数を増やして分散処理する

どんな時に必要か

  • システム負荷増大時の対応
  • サービス成長に合わせた拡張

3. 可用性・信頼性

フェイルオーバー

  • 意味
    障害発生時に自動的に待機系(スタンバイ)に切り替える仕組み。

どんな時に必要か

  • 高可用性が求められるシステム(金融、医療など)

冗長化(Redundancy)

  • 意味
    システムの一部が故障しても全体が停止しないようにする設計。

    • サーバーの二重化
    • ネットワーク経路の多重化

どんな時に必要か

  • ミッションクリティカルなサービス
  • SLA(サービスレベル合意)遵守

バックアップ

  • 意味
    データの複製を定期的に保存し、障害時に復元できるようにする。

  • 種類

    • フルバックアップ
    • 差分バックアップ
    • 増分バックアップ

どんな時に必要か

  • データ消失リスク対策
  • 法令遵守(ログ保存義務など)

4. セキュリティ

認証(Authentication)・認可(Authorization)

  • 認証
    ユーザーが誰かを確認する(例:ID/パスワード、OAuth、SAML)

  • 認可
    認証済みユーザーが何をできるかを制御する(例:管理者権限、閲覧権限)

どんな時に必要か

  • ログイン機能
  • 管理画面やAPIのアクセス制御

CSRF/XSS/SQL Injection

  • CSRF(クロスサイトリクエストフォージェリ)
    ユーザーの意図しないリクエストを第三者が送信させる攻撃

  • XSS(クロスサイトスクリプティング)
    悪意あるスクリプトをWebページに埋め込む攻撃

  • SQL Injection
    SQL文に悪意あるコードを挿入し、データベースを不正操作する攻撃

どんな時に必要か

  • Webサービス全般のセキュリティ対策

暗号化

  • 意味
    データを第三者に読まれないように変換する

  • 種類

    • 通信の暗号化(HTTPS, TLS)
    • データの暗号化(AES, RSA)

どんな時に必要か

  • 個人情報や機密情報の取り扱い
  • 法令遵守(GDPR, 個人情報保護法)

5. 分散システム・アーキテクチャ

CAP定理

  • 意味
    分散システムにおいて「一貫性(Consistency)」「可用性(Availability)」「分断耐性(Partition Tolerance)」のうち2つしか同時に満たせないという理論。

    • RDBはCA(分断耐性を犠牲)
    • NoSQLはAPやCPを選択

どんな時に必要か

  • 分散DBやマイクロサービス設計時のトレードオフ判断

イベントソーシング

  • 意味
    全ての状態変化を「イベント」として記録し、状態を再現する設計パターン。

  • メリット

    • 監査証跡が残る
    • 状態の再現が容易

どんな時に必要か

  • 監査証跡が必要なシステム
  • 複雑なビジネスロジックの履歴管理

CQRS(Command Query Responsibility Segregation)

  • 意味
    データの更新(コマンド)と参照(クエリ)を分離する設計パターン。

  • メリット

    • 読み取り・書き込みのスケール戦略を分けられる
    • 複雑なドメインロジックの整理

どんな時に必要か

  • 大規模システムのパフォーマンス最適化
  • 読み取りと書き込みの負荷バランスが大きく異なる場合

メッセージキュー

  • 意味
    非同期処理やシステム間連携のためのメッセージ送受信基盤(例:RabbitMQ, Kafka, SQS)

  • 用途

    • バッチ処理
    • マイクロサービス間通信
    • リトライ処理

どんな時に必要か

  • 処理の非同期化
  • システム間の疎結合化

サーキットブレーカー

  • 意味
    外部サービスやAPIの障害発生時に、システム全体への影響を最小限に抑える仕組み。

  • 動作例

    • 一定回数失敗したら外部APIへのリクエストを遮断し、即時エラーを返す

どんな時に必要か

  • 外部API連携時の障害対策
  • システムの健全性維持

6. その他

モニタリング・アラート

  • 意味
    システムの稼働状況や異常を監視し、問題発生時に通知する仕組み。

  • ツール例

    • Prometheus
    • Datadog
    • CloudWatch

どんな時に必要か

  • 障害の早期発見・対応
  • SLA遵守

オブザーバビリティ(可観測性)

  • 意味
    システムの内部状態を外部から把握できる能力。
    ログ、メトリクス、トレースの3本柱。

どんな時に必要か

  • 複雑な分散システムの運用
  • 障害解析やパフォーマンスチューニング

まとめ

システム設計では、上記のような用語や概念を理解し、適切な場面で使い分けることが重要です。
面接や実務で「なぜその設計を選んだのか?」を説明できるよう、背景やトレードオフも意識しましょう。


参考文献

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?