導言工欲善其事、必ず先ず其の器を利す；士其の義を宣べんと欲せば、必ず先ず其の書を読む。バックエンド開発はインターネット技術分野の掌中の明珠として、常に開発者たちが追い求める高峰である。本文では、バックエンド開発に関わる技術用語を出発点とし、システム開発、アーキテクチャ設計、ネットワーク通信などの側面から、バックエンド開発について読者が明確な理解を得られるよう、分かりやすく全面的に解説する。（作者：willlv）
システム開発
- 高凝集/低結合
高凝集とは、ソフトウェアモジュールが関連性の高いコードで構成され、単一のタスクのみを担当することを指し、いわゆる単一責任の原則である。モジュールの凝集度は、モジュール内部の結びつきの緊密度を反映する。
モジュール間の結びつきが緊密であればあるほど、その結合度は強くなり、モジュールの独立性は低くなる。モジュール間の結合度の高低は、モジュール間のインターフェースの複雑さ、呼び出し方法、渡される情報によって決まる。完全なシステムでは、モジュールとモジュールの間は可能な限り独立して存在させるべきである。通常、プログラム構造において各モジュールの凝集度が高いほど、モジュール間の結合度は低くなる。
- 過度な設計
過度な設計とは、将来を見据えた設計を過剰に行うこと、または比較的単純なことを複雑に考えすぎることである。モジュール化、拡張性、デザインパターンなどを過度に追求し、システムに不必要な複雑さを追加することになる。
- 早期最適化
早期とは、開発プロセスの初期段階ではなく、まだ要件の将来の変化の方向性が明らかになっていない時点を指す。あなたの最適化は、新しい要件をうまく実現できない可能性があるだけでなく、最適化の予想が間違っている可能性もあり、コードが複雑になっただけで何も得られないという結果になりかねない。
正しい方法は、まず質の高い状態で要件を実装し、十分なテストケースを書き、その後プロファイルを取ってパフォーマンスのボトルネックを見つけ、その時点で最適化を行うことである。
- リファクタリング
リファクタリングとは、プログラムコードを調整することでソフトウェアの品質やパフォーマンスを改善し、そのプログラムの設計パターンやアーキテクチャをより合理的にし、ソフトウェアの拡張性と保守性を高めることである。
- 割れ窓効果
割れ窓理論とも呼ばれる。割れ窓効果（Broken windows theory）は犯罪学の理論である。この理論は、環境内の悪い現象が放置されると、人々がそれを模倣し、さらには悪化させることを誘発すると考える。少し割れた窓がある建物を例にとると、その窓が修理されなければ、破壊者がさらに多くの窓を壊すかもしれない。最終的には建物内に侵入し、無人であることがわかれば、そこに住み着いたり放火したりするかもしれない。
これをソフトウェア工学に応用すると、システムコードやアーキテクチャ設計の不具合の兆候を決して蔓延させてはならない。時間が経つにつれて不具合はより深刻になる。逆に、本来質の高いシステムは、人に質の高いコードを書かせるものである。
- 相互不信の原則
プログラムの実行における上流から下流までの全リンクにおいて、各ポイントは絶対に信頼できるとは限らず、どのポイントもいつでも障害や予測不能な動作（マシンネットワーク、サービス自体、依存環境、入力やリクエストなど）を起こす可能性があるため、あらゆる場所に防御策を講じる必要があるという原則である。
- 永続化
永続化とは、プログラムデータを一時的な状態と永続的な状態の間で変換するメカニズムである。平たく言えば、一時的なデータ（メモリ上のデータなど、永続的に保存できないもの）を永続的なデータ（データベースやローカルディスクに保存され、長期保存が可能なもの）に変換することである。
- クリティカルセクション
クリティカルセクションとは、複数のスレッドが使用できる共通リソースまたは共有データを表すが、一度に使用できるのは1つのスレッドのみである。クリティカルセクションのリソースが占有されると、他のスレッドがこのリソースを使用したい場合、待機しなければならない。
- ブロッキング/ノンブロッキング
ブロッキングとノンブロッキングは、通常、マルチスレッド間の相互影響を表す。例えば、あるスレッドがクリティカルセクションのリソースを占有している場合、そのリソースを必要とする他のすべてのスレッドはこのクリティカルセクションで待機する必要があり、待機はスレッドの一時停止を引き起こす。この状態をブロッキングと呼ぶ。このとき、リソースを占有しているスレッドがリソースを解放しない場合、このクリティカルセクションでブロックされている他のすべてのスレッドは作業できない。ノンブロッキングは、複数のスレッドが同時にクリティカルセクションに入ることを許可する。
- 同期/非同期
通常、同期と非同期は関数/メソッド呼び出しに関連する。
同期とは、関数呼び出しを発行したとき、結果が得られるまでその呼び出しは戻らないことをいう。非同期呼び出しはすぐに戻るが、非同期呼び出しがすぐに戻るからといってタスクが完了したわけではなく、バックグラウンドでスレッドを起動してタスクを続行し、タスクが完了するとコールバックなどを介して呼び出し元に通知する。
- 並行/並列
並列（parallel）
同一時刻に、複数の命令が複数のプロセッサ上で同時に実行されることを指す。したがって、ミクロな視点でもマクロな視点でも、両者は一緒に実行されている。
並行（concurrency）
同一時刻には1つの命令しか実行できないが、複数のプロセス命令が高速に切り替えられて実行されるため、マクロ的には複数のプロセスが同時に実行されているように見えるが、ミクロ的には同時実行ではなく、時間を複数の断片に分割して複数のプロセスを高速に交互に実行させている。
アーキテクチャ設計
- 高並行（High Concurrency）
分散システムの登場により、高並行（High Concurrency）は通常、システムが多くのリクエストを同時に並行処理できるように設計することを指す。通俗的に言えば、高並行とは、同じ時点で多くのユーザーが同時に同じAPIインターフェースやURLアドレスにアクセスすることを指す。これは、アクティブユーザー数が多く、ユーザーが集中するビジネスシナリオでよく発生する。
- 高可用性（High Availability）
高可用性HA（High Availability）は、分散システムアーキテクチャ設計において考慮すべき要素の一つである。通常、システムが特別に設計され、ダウンタイムを削減し、そのサービスの高度な可用性を維持することを指す。
- 読み取り/書き込み分離
データベース製品の安定性を確保するため、多くのデータベースは二重化ホットスタンバイ機能を備えている。つまり、1台目のデータベースサーバーは、追加・削除・変更の業務を提供する本番サーバーであり、2台目のデータベースサーバーは主に読み取り操作を行う。
- コールドスタンバイ/ホットスタンバイ
コールドスタンバイ：2台のサーバーがあり、1台は稼働し、もう1台はバックアップとして稼働しない。これにより、稼働中のサーバーがダウンした場合、バックアップサーバーを起動させる。コールドスタンバイの方式は比較的実装が容易だが、欠点はホストに障害が発生した場合に待機系が自動的に引き継がず、手動でサービスを切り替える必要があることである。ホットスタンバイ：一般的にアクティブ/スタンバイ方式と呼ばれるものである。サーバーデータ（データベースデータを含む）を同時に2台以上のサーバーに書き込む。アクティブサーバーに障害が発生した場合、ソフトウェアによる診断（通常はハートビート診断）によってスタンバイマシンをアクティブにし、アプリケーションが短時間で完全に正常に使用できるようにする。1台のサーバーがダウンした場合、自動的に別の待機サーバーに切り替えて使用する。
- 地理的マルチアクティブ
地理的マルチアクティブとは、通常、異なる都市に独立したデータセンターを構築することを指す。「アクティブ」とはコールドバックアップに対する概念であり、コールドバックアップは全量データをバックアップし、通常はビジネス要件を支えず、メインのデータセンターに障害が発生した場合にのみバックアップデータセンターに切り替える。一方、マルチアクティブとは、これらのデータセンターが日常の業務でもトラフィックを処理し、ビジネスを支えることを指す。
- 負荷分散（ロードバランシング）
負荷分散（ロードバランシング）は、複数のサーバーに対してトラフィックを分散する負荷分散サービスである。複数のインスタンス間でアプリケーションの対外サービス能力を自動的に配分し、単一障害点を排除することでアプリケーションシステムの可用性を向上させ、より高いレベルのアプリケーション耐障害性を実現し、アプリケーショントラフィックの分散に必要な負荷分散容量をシームレスに提供し、効率的で安定した安全なサービスを提供する。
- 静的コンテンツと動的コンテンツの分離
静的コンテンツと動的コンテンツの分離とは、Webサーバーアーキテクチャにおいて、静的ページと動的ページ、または静的コンテンツインターフェースと動的コンテンツインターフェースを異なるシステムでアクセスさせるアーキテクチャ設計手法であり、これによりサービス全体のアクセス性能と保守性を向上させる。
- クラスタ
単一サーバーの同時処理能力には限りがある。単一サーバーの処理能力がパフォーマンスのボトルネックに達した場合、複数のサーバーを組み合わせてサービスを提供する。この組み合わせ方式をクラスタと呼び、クラスタ内の各サーバーをそのクラスタの「ノード」と呼ぶ。各ノードは同じサービスを提供でき、システム全体の並行処理能力が倍増する。
- 分散
分散システムとは、完全なシステムをビジネス機能に従って多くの独立したサブシステムに分割したもので、各サブシステムは「サービス」と呼ばれる。分散システムはリクエストを異なるサブシステムに選別・配信し、異なるサービスに異なるリクエストを処理させる。分散システムでは、サブシステムは独立して動作し、それらの間はネットワーク通信を介して接続され、データの相互運用と複合サービスを実現する。
- CAP理論
CAP理論とは、分散システムにおいて、一貫性（Consistency）、可用性（Availability）、分散トレランス（Partition Tolerance）の3つを同時に満たすことはできないという理論である。
一貫性：同一時点において、分散システム内のすべてのデータバックアップが同じであるか、同じ状態にあることを要求する。
可用性：システムクラスタの一部のノードがダウンしても、システムがユーザーのリクエストに正しく応答できること。
分散トレランス：ノード間のネットワーク通信の障害をシステムが許容できること。
簡単に言えば、分散システムでは、上記の2つのプロパティまでしかサポートできない。しかし、明らかに分散である以上、パーティション分割は必然であり、パーティションエラーを100%避けることはできない。したがって、一貫性と可用性の間で選択を迫られることになる。
分散システムでは、しばしば可用性を追求する。可用性の重要性は一貫性よりも高い。では、どのようにして高可用性を実現するのか。ここにBASE理論があり、CAP理論をさらに拡張する。
- BASE理論
BASE理論は次のように述べる：
Basically Available（基本可用）
Soft state（ソフトステート）
Eventually consistent（結果整合性）
BASE理論は、CAPの一貫性と可用性をトレードオフした結果である。理論の核心は、強整合性を実現することはできないが、各アプリケーションは自身のビジネス特性に応じて適切な方法でシステムを最終的に整合性のある状態にすることができるということである。
- 水平スケールアップ/垂直スケールアップ
水平スケールアップ Scale Outより多くのサーバーやプログラムインスタンスを追加することで負荷を分散し、ストレージ能力と計算能力を向上させる。垂直スケールアップ Scale Up単一マシンの処理能力を向上させる。
垂直スケールアップには2つの方法がある：
（1）単一マシンのハードウェア性能を強化する。例：CPUコア数を32コアに増やす、より優れたネットワークカードにアップグレードする（例：10ギガビット）、より優れたハードディスクにアップグレードする（例：SSD）、ハードディスク容量を拡張する（例：2TB）、システムメモリを拡張する（例：128GB）。
（2）単一マシンのソフトウェアまたはアーキテクチャの性能を向上させる。例：Cacheを使用してIO回数を減らす、非同期を使用して単一サービスのスループットを増やす、ロックフリーのデータ構造を使用して応答時間を短縮する。
- 水平拡張（パラレル拡張）
水平スケールアップと類似している。クラスタサーバーのノードはすべて並列な対等ノードであり、拡張が必要な場合、より多くのノードを追加することでクラスタのサービス能力を向上させることができる。一般的に、サーバーの重要なパス（例：ログイン、決済、コアビジネスロジックなど）は、実行時に動的な水平拡張をサポートする必要がある。
- 弾力性拡張
デプロイされたクラスタを動的にオンラインで拡張することを指す。弾力性拡張システムは、実際のビジネス環境に応じて一定の戦略に従って自動的により多くのノード（ストレージノード、計算ノード、ネットワークノードを含む）を追加することで、システム容量を増やし、システム性能を向上させ、またはシステムの信頼性を強化するか、あるいはこれら3つの目標を同時に達成する。
- 状態同期/フレーム同期
- 状態同期：状態同期とは、サーバーがすべてのゲームロジックを計算し、これらの計算結果をブロードキャストする責任を負い、クライアントは単にプレイヤーの操作を送信し、受け取ったゲーム結果を表現するだけであることを指す。
特徴：状態同期は安全性が高く、ロジックの更新が容易で、再接続が速いが、開発効率は低く、ネットワークトラフィックはゲームの複雑さに応じて増加し、サーバーはより大きな負荷を支える必要がある。
フレーム同期：サーバーはメッセージを転送するだけで、論理処理は一切行わない。各クライアントの1秒あたりのフレーム数は一定であり、各フレームで同じ入力データを処理する。
特徴：フレーム同期では、システムが同じ入力に対して同じ出力を出すことを保証する必要がある。フレーム同期は開発効率が高く、トラフィック消費が低く安定しており、サーバーへの負荷が非常に小さい。しかし、ネットワーク要件が高く、再接続に時間がかかり、クライアントの計算負荷が大きい。
ネットワーク通信
- コネクションプール
事前に接続バッファプールを確立し、接続の使用、割り当て、管理に関する一連の戦略を提供することで、プール内の接続を効率的かつ安全に再利用できるようにし、接続の頻繁な確立と切断のオーバーヘッドを回避する。
- 切断再接続
ネットワークの変動によりユーザーが断続的にサーバーとの接続を切断する場合、ネットワークが回復した後にサーバーがユーザーを前回切断時の状態とデータに再接続しようとする試み。
- セッション維持
セッション維持とは、ロードバランサーにおけるメカニズムで、クライアントとサーバー間の対話プロセスの関連性を識別し、負荷分散を行いながら、関連する一連のアクセス要求がすべて1台のマシンに割り当てられるように保証する。平たく言えば、1回のセッション中に発行される複数のリクエストがすべて同じマシンに着地することである。
- 長接続/短接続
通常、TCPの長接続と短接続を指す。長接続はTCP接続を確立した後、その接続を維持し続けるもので、通常は互いにハートビートを送信して存在を確認し、その間に複数の業務データ転送を行い、一般的には能動的に接続を切断しない。短接続は通常、接続を確立した後、1つのトランザクション（例：HTTPリクエスト）を実行した後、接続を切断する。
- フロー制御/輻輳制御
フロー制御送信側が速すぎる送信で受信側のリソースを使い果たし、受信側が処理できなくなるのを防ぐ。輻輳制御送信側が速すぎる送信でネットワークが処理できずに輻輳を引き起こし、その部分やネットワーク全体の性能低下、深刻な場合にはネットワーク通信の停止につながるのを防ぐ。
- シリアスグループ（thundering herd）
シリアスグループ現象は、マルチプロセス（マルチスレッド）が同じイベントを待って同時にブロックしている（スリープ状態）場合、そのイベントが発生すると、待機中のすべてのプロセス（またはスレッド）を起こすが、最終的にそのイベントの「制御権」を獲得して処理できるのは1つのプロセス（またはスレッド）だけであり、他のプロセス（またはスレッド）は「制御権」の獲得に失敗し、再びスリープ状態に入らなければならない。この現象と性能の浪費をシリアスグループと呼ぶ。
- NAT
NAT（Network Address Translation、ネットワークアドレス変換）は、IPパケットヘッダーのアドレス情報を置き換えることである。NATは通常、組織のネットワーク出口に配置され、内部ネットワークIPアドレスを出口IPアドレスに置き換えることで、公網到達性と上位プロトコルの接続能力を提供する。
障害・異常
- ダウン
ダウンとは、一般的にコンピュータのホストが予期しない障害で停止することを指す。次に、一部のサーバー（データベースのデッドロックなど）もダウンと呼ぶことがあり、サーバーの一部のサービスが停止した場合にもこう言うことがある。
- コアダンプ
プログラムがエラーで異常終了した場合、OSはプログラムの現在の動作状態をcoredumpファイルとして保存する。通常、coredumpファイルにはプログラム実行時のメモリ、レジスタ状態、スタックポインタ、メモリ管理情報などが含まれる。
- キャッシュ貫通/キャッシュ破綻/キャッシュ雪崩
キャッシュ貫通：キャッシュ貫通とは、絶対に存在しないデータを問い合わせることで、キャッシュにない場合はデータベースから問い合わせる必要があり、データが見つからないとキャッシュに書き込まれないため、この存在しないデータへのリクエストが毎回データベースに問い合わせることになり、データベースに負荷がかかる。
キャッシュ破綻：キャッシュ破綻とは、ホットキーが特定の時点で期限切れになる際、ちょうどその時点でそのキーに対して大量の同時リクエストが発生し、大量のリクエストがDBに到達することである。
キャッシュ雪崩：キャッシュ雪崩とは、キャッシュ内のデータが大量に一斉に期限切れになり、問い合わせデータ量が膨大で、データベースの負荷が大きくなりすぎてダウンする可能性があることである。
キャッシュ破綻との違い：キャッシュ破綻はホットキーの失効であり、キャッシュ雪崩は大量のキーが同時に失効することである。
- 500/501/502/503/504/505
500 Internal Server Error：内部サーバーエラー。通常、サーバーが予期しない状況に遭遇し、リクエストを完了できない。考えられる原因：1、プログラムエラー（例：ASPやPHPの構文エラー）、2、高並行によるシステムリソース制限（開けるファイル数が多すぎるため）。501 Not Implemented：サーバーがリクエストのHTTPメソッドを理解していないか、サポートしていない。502 Bad Gateway：WEBサーバー障害。原因として、プログラムプロセスが不足している可能性がある。リクエストされたphp-fpmが実行されたが、何らかの理由で実行が完了せず、結果的にphp-fpmプロセスが終了した。考えられる原因：1、Nginxサーバーでphp-cgiプロセス数が不足、2、PHPの実行時間が長すぎる、3、php-cgiプロセスが停止。503 Service Unavailable：サーバーが現在利用できない。システムメンテナンスによりサーバーが一時的にクライアントのリクエストを処理できない。これは一時的な状態である。サーバー提供元に連絡されたい。504 Gateway Timeout：サーバー504エラーはタイムアウトを示す。クライアントが送信したリクエストがゲートウェイに到達しなかった、つまりリクエストが実行可能なphp-fpmに到達しなかったことを意味し、通常はnginx.confの設定に関連する。505 HTTP Version Not Supported：サーバーがリクエストで使用されたHTTPプロトコルバージョンをサポートしていない（HTTPバージョンがサポートされていない）。
500エラーがプログラム言語のエラーである可能性がある以外は、その他のエラーはサーバーまたはサーバー設定に問題があると理解してよい。
- メモリオーバーフロー/メモリリーク
メモリオーバーフロー：メモリオーバーフロー（Out Of Memory）とは、プログラムがメモリを要求した際に、要求者に十分なメモリがない場合、またはint型データを格納するためのメモリ領域を与えたが、long型データを格納しようとした場合、メモリが不足し、エラーOOMが発生することをいう。メモリリーク：メモリリーク（Memory Leak）とは、プログラムで動的に割り当てられたヒープメモリが、何らかの理由でプログラムによって解放されず、または解放できず、システムメモリを浪費し、プログラムの実行速度低下やシステムクラッシュなどの深刻な結果を引き起こすことである。
- ハンドルリーク
ハンドルリークとは、プロセスがシステムファイルを呼び出した後、開いたファイルハンドルを解放しないことである。一般的に、ハンドルリークが発生すると、マシンが遅くなり、CPU使用率が上昇し、ハンドルリークが発生したCGIやサーバーのCPU使用率が増加する。
- デッドロック
デッドロックとは、2つ以上のスレッドが実行中に、リソースの競合や相互通信によりブロック状態になり、外力がなければそれらはすべてブロック状態のまま進行できなくなる現象を指す。このときシステムはデッドロック状態にある、またはデッドロックが発生したという。
- ソフト割り込み/ハード割り込み
ハード割り込み：通常、私たちが割り込みと呼ぶものはハード割り込み（hardirq）を指す。
システムに接続された周辺機器（ネットワークカード、ハードディスクなど）によって自動的に生成される。
主にOSに周辺機器の状態変化を通知するために使用される。
ソフト割り込み：1、通常、ハード割り込みサービスルーチンがカーネルに対して行う割り込み。2、リアルタイムシステムの要件を満たすため、割り込み処理はできるだけ高速であるべきである。
Linuxはこの特性を実現するため、割り込みが発生すると、ハード割り込みは短時間で完了できる処理を行い、処理に時間がかかる作業は割り込みの後にソフト割り込み（softirq）として処理する。
- スパイク
ごく短い瞬間に、サーバーの性能指標（トラフィック、ディスクIO、CPU使用率など）が前後の時間帯よりもはるかに大きくなること。スパイクの出現は、サーバーリソースの利用が不均一で不十分であることを示し、他のより深刻な問題を誘発しやすい。
- リプレイアタック
攻撃者が、目的のホストが既に受信したパケットを再送信し、システムを欺くことを目的とする。主に認証プロセスで使用され、認証の正確性を破壊する。これは攻撃の一種であり、有効なデータ転送を悪意を持って、または詐欺的に繰り返す。リプレイアタックは発信者によって行われることもあれば、データを傍受して再送信する敵対者によって行われることもある。攻撃者はネットワーク傍受などの方法で認証情報を盗み、それを再び認証サーバーに送信する。
- ネットワーク孤立
ネットワーク孤立とは、クラスタ環境において、一部のマシンがクラスタ全体とのネットワーク接続を失い、小さなクラスタに分裂し、データの不整合が発生する状態を指す。
- データスキュー
クラスタシステムでは、通常、キャッシュは分散されており、異なるノードが一定範囲のキャッシュデータを担当する。キャッシュデータの分散度が不十分で、大量のキャッシュデータが1台または数台のサービスノードに集中することをデータスキューと呼ぶ。データスキューは通常、負荷分散の効果が不十分であることに起因する。
- スプリットブレイン
スプリットブレインとは、クラスタシステムにおいて、一部のノード間でネットワークが到達不能になりシステムが分裂し、分裂した小さなクラスタがそれぞれの状態でサービスを提供し、元のクラスタに一貫性のない反応が同時に存在し、ノード間でリソースを奪い合い、システムが混乱し、データが破損する状態を指す。
監視とアラート
- サービス監視
サービス監視の主な目的は、サービスに問題が発生した場合、または問題が発生しそうな場合に、正確かつ迅速に発見し、影響範囲を最小限に抑えることである。サービス監視には一般的に複数の手段があり、階層別に分類できる：
システム層（CPU、ネットワーク状態、IO、マシン負荷など）
アプリケーション層（プロセス状態、エラーログ、スループットなど）
ビジネス層（サービス/インターフェースのエラーコード、応答時間）
ユーザー層（ユーザー行動、世論監視、フロントエンドトラッキング）
- フルリンク監視
サービスプロービング：サービスプロービングは、サービス（アプリケーション）の可用性を検出する監視方法であり、プロービングノードが対象サービスを定期的にプローブする。主に可用性と応答時間で測定され、プロービングノードは通常、複数の異なる場所に存在する。
ノードプロービング：ノードプロービングは、異なるデータセンター（データセンター）ノード間のネットワーク可用性と到達性を発見・追跡する監視方法であり、主に応答時間、パケットロス率、ホップ数で測定される。プロービング方法は通常、ping、mtr、または他の独自プロトコルである。
アラートフィルタリング：予測可能な特定のアラートをフィルタリングし、アラート統計データに含めない。例えば、少量のクローラーアクセスによるHTTP 500エラー、ビジネスシステムのカスタム例外情報など。
アラート重複排除：アラート通知が担当者に送信された後、そのアラートが回復するまで、同じアラートは引き続き受信されない。
アラート抑制：システムの揺れによるノイズを減らすため、抑制も実装する必要がある。例えば、サーバーの瞬間的な高負荷は正常である可能性があり、一定期間持続する高負荷のみが重要視されるべきである。
アラート回復：開発/運用担当者はアラート通知を受け取るだけでなく、障害が解消されアラートが正常に戻った通知も受け取る必要がある。
アラートマージ：同一時刻に発生した複数の同一アラートをマージする。例えば、あるマイクロサービス・クラスタで同時に複数のサブサービスが高負荷のアラートを発生させた場合、1つのアラートにマージする必要がある。
アラート収束：あるアラートが発生したとき、他のアラートを伴うことがよくある。この場合、根本原因に対してのみアラートを発生させ、他のアラートは子アラートとして収束し、一緒に通知を送ることができる。例えば、クラウドサーバーでCPU負荷アラートが発生した場合、それに搭載されているすべてのシステムの可用性アラートが伴うことが多い。
障害自己治癒：アラートをリアルタイムで発見し、事前診断分析を行い、障害を自動回復し、周辺システムと連携してプロセス全体のクローズドループを実現する。
サービスガバナンス
- マイクロサービス
マイクロサービスアーキテクチャはアーキテクチャパターンの一種であり、単一のアプリケーションを小さなサービスの集合に分割することを提唱する。サービス間は相互に協調・協力し、ユーザーに最終的な価値を提供する。各サービスは独立したプロセスで実行され、サービス間は軽量な通信メカニズム（通常はHTTPベースのRESTful API）で相互に通信する。各サービスは特定のビジネスを中心に構築され、本番環境やステージング環境などに独立してデプロイできる。
- サービスディスカバリ
サービスディスカバリとは、レジストリを使用して分散システム内のすべてのサービスの情報を記録し、他のサービスがこれらの登録済みサービスを迅速に見つけられるようにすることである。サービスディスカバリは、大規模SOAやマイクロサービスアーキテクチャを支えるコアモジュールであり、可能な限り高可用性を実現する必要がある。
- トラフィックピークカット
抽選やフラッシュセールシステムのリクエスト監視曲線を見ると、このようなシステムはイベントの開放時間帯にピークが現れ、イベント非開放時にはシステムのリクエスト量やマシン負荷は一般的に安定している。マシンリソースを節約するため、短時間の高負荷リクエストに対応するために常に最大限のリソース能力を提供することは不可能である。そのため、瞬間的なリクエストピークを緩和し、高負荷リクエスト下でもシステムのスループットを制御可能に保つための技術的手段を使用する必要がある。ピークカットはスパイクを除去し、サーバーリソースの利用をより均等かつ十分にするためにも使用できる。一般的なピークカット戦略には、キューイング、周波数制限、階層的フィルタリング、マルチレベルキャッシュなどがある。
- バージョン互換性
バージョンアップの過程では、新しいデータ構造が古いデータを理解・解析できるか、新しいプロトコルが古いプロトコルを理解し、期待される適切な処理を行えるかを考慮する必要がある。これにはサービス設計においてバージョン互換性を確保することが求められる。
- 過負荷保護
過負荷とは、現在の負荷がシステムの最大処理能力を超えている状態を指す。過負荷が発生すると、一部のサービスが利用不可になり、適切に対処しなければ、サービス完全停止や雪崩を引き起こす可能性が高い。過負荷保護は、このような異常状態に対して、サービス完全停止を防ぐための対策である。
- サーキットブレーカー
サーキットブレーカーの役割は家庭用のヒューズに似ており、あるサービスが利用不可になったり応答がタイムアウトした場合、システム全体の雪崩を防ぐために、そのサービスの呼び出しを一時的に停止する。
- サービスダウングレード
サービスダウングレードとは、サーバーの負荷が急激に増加した場合、現在のビジネス状況とトラフィックに応じて、一部のサービスやページを戦略的にダウングレードし、サーバーリソースを解放してコアタスクの正常な実行を確保することである。ダウングレードはしばしば異なるレベルを指定し、異なる異常レベルに対して異なる処理を実行する。
サービスの方法に応じて：サービスを拒否する、サービスを遅延させる、ランダムにサービスを提供することもある。
サービスの範囲に応じて：特定の機能を削除する、特定のモジュールを削除することもある。
要するに、サービスダウングレードは異なるビジネス要件に応じて異なるダウングレード戦略を採用する必要がある。主な目的はサービスに損害があっても、全くないよりはましであることだ。
- サーキットブレーカー vs ダウングレード
共通点：
目標は一致しており、可用性と信頼性から出発し、システムのクラッシュを防ぐこと。ユーザー体験も類似しており、最終的にユーザーは一部の機能が一時的に利用不可であることを体験する。相違点：
トリガー原因が異なる。サーキットブレーカーは通常、あるサービス（下流サービス）の障害によって引き起こされるが、サービスダウングレードは一般的に全体的な負荷を考慮して行われる。
- サービスレート制限
レート制限はサービスダウングレードの一種と考えることができる。レート制限はシステムの入出力トラフィックを制限し、システムを保護することを目的とする。一般的に、システムのスループットは見積もり可能であり、システムの安定動作を保証するため、制限すべきしきい値に達した場合、トラフィックを制限し、レート制限の目的を達成するための対策（遅延処理、拒否処理、または一部拒否処理など）を講じる必要がある。
- 障害遮断
障害のあるマシンをクラスタから除外し、新しいリクエストが障害マシンに振り分けられないようにする。
テスト手法
- ブラックボックステスト/ホワイトボックステスト
ブラックボックステストは、プログラムの内部構造や論理構造を考慮せず、主にシステムの機能が要件仕様書を満たしているかをテストする。一般的には入力値があり、出力値があり、期待値と比較する。
ホワイトボックステストは主に単体テスト段階で適用され、コードレベルのテストである。プログラムの内部論理構造を対象とし、テスト手法には：文網羅、判定網羅、条件網羅、経路網羅、条件組み合わせ網羅がある。
- 単体テスト/統合テスト/システムテスト/受け入れテスト
ソフトウェアテストは一般に4つの段階に分けられる：単体テスト、統合テスト、システムテスト、受け入れテスト。
単体テスト：単体テストは、ソフトウェア内の最小の検証可能な単位（モジュール、プロシージャ、メソッドなど）を検査・検証する。単体テストの粒度は最も小さく、通常は開発チームがホワイトボックス方式で実施し、主に単体が「設計」に適合しているかをテストする。統合テスト：統合テストはアセンブリテストとも呼ばれ、通常は単体テストの上に、すべてのプログラムモジュールを順序立てて段階的にテストする。統合テストは単体テストとシステムテストの間に位置し、「ブリッジの役割」を果たす。通常は開発チームがホワイトボックスとブラックボックスの組み合わせでテストし、「設計」と「要件」の両方を検証する。システムテスト：システムテストは、統合テストを経たソフトウェアをコンピュータシステムの一部として、システム内の他の部分と結合し、実際の運用環境で一連の厳格かつ効果的なテストを実施し、ソフトウェアの潜在的な問題を発見し、システムの正常な動作を保証する。システムテストの粒度は最も大きく、通常は独立したテストチームがブラックボックス方式で実施し、主にシステムが「要件仕様書」に適合しているかをテストする。受け入れテスト：受け入れテストは納品テストとも呼ばれ、ユーザー要件やビジネスプロセスに基づいて正式に実施されるテストであり、システムが受け入れ基準を満たしているかを判断し、システムを受け入れるかどうかをユーザー、顧客、またはその他の権限機関が決定する。受け入れテストはシステムテストと似ているが、主な違いはテスターであり、受け入れテストはユーザーが実施する。
- 回帰テスト
欠陥を発見・修正した後、またはソフトウェアに新しい機能を追加した後、再テストを実施する。修正された欠陥が正しく修正されたか、および変更が新しい問題を引き起こしていないかを確認するために行う。
- スモークテスト
この用語はハードウェア業界に由来する。ハードウェアまたはハードウェアコンポーネントに変更や修正を加えた後、デバイスに直接通電する。煙が出なければ、そのコンポーネントはテストを通過したことになる。ソフトウェアにおいて、「スモークテスト」という用語は、コード変更を製品のソースツリーに組み込む前に、その変更を検証するプロセスを指す。
スモークテストは、ソフトウェア開発プロセスにおけるソフトウェアバージョンパッケージに対する迅速な基本機能検証戦略であり、ソフトウェアの基本機能を確認・検証する手段であり、ソフトウェアバージョンパッケージの詳細なテストではない。
例えば、ログインシステムのスモークテストでは、正しいユーザー名とパスワードを入力してログインするというコア機能ポイントをテストするだけで十分であり、入力ボックスや特殊文字などはスモークテストの後で行うことができる。
- パフォーマンステスト
パフォーマンステストは、自動化されたテストツールを使用して、正常、ピーク、異常負荷などのさまざまな条件をシミュレートし、システムの各性能指標をテストする。負荷テストとストレステストはどちらもパフォーマンステストに属し、両者を組み合わせて実施することができる。
負荷テストにより、さまざまな作業負荷下でのシステムの性能を特定する。目標は、負荷が徐々に増加するにつれて、システムの各性能指標の変化をテストすることである。
ストレステストは、システムのボトルネックまたは許容できない性能ポイントを特定し、システムが提供できる最大のサービスレベルを取得するテストである。
- ベンチマークテスト
ベンチマークテストもパフォーマンステストの一種であり、マシンのハードウェアの最高実効性能、およびソフトウェア最適化による性能向上効果を測定するために使用される。また、特定のコードのCPUやメモリ効率の問題を特定するためにも使用できる。多くの開発者はベンチマークテストを使用して異なる並行パターンをテストしたり、ワーカープールの数を設定してシステムのスループットを最大化するための補助として使用する。
- A/Bテスト
A/Bテストは、ランダムに割り当てられた2つ以上の類似したサンプルグループを対比する。実験グループと対照グループの実験結果が目標指標において統計的に有意であれば、実験グループの機能が望む結果をもたらすと言え、仮説の検証や製品決定の支援に役立つ。
- コードカバレッジテスト
コードカバレッジ（Code coverage）はソフトウェアテストにおける尺度の一つで、プログラム内のソースコードがテストされた割合と程度を記述し、得られた割合をコードカバレッジと呼ぶ。単体テストを行う際、コードカバレッジはテストの良し悪しを測る指標としてよく使われる。さらには、コードカバレッジでテストタスクの完了状況を評価することもあり、例えばコードカバレッジが80%または90%に達しなければならないなど。そのため、テスターはコードを網羅するためにテストケースの設計に苦心する。
リリースとデプロイ
- DEV/PRO/FAT/UAT
DEV（Development environment）：開発環境。開発者がデバッグ用に使用する。バージョンの変更が大きい。FAT（Feature Acceptance Test environment）：機能受け入れテスト環境。ソフトウェアテスターがテスト用に使用する。UAT（User Acceptance Test environment）：ユーザー受け入れテスト環境。本番環境での機能検証用であり、プレリリース環境として使用できる。PRO（Production environment）：本番環境。正式なオンライン環境。
- カナリアリリース
カナリアリリースとは、バージョンアップの過程で、パーティション制御やホワイトリスト制御などを通じて、一部のユーザーに先に新機能をリリースし、残りのユーザーはそのままにしておく。しばらくして新機能をリリースしたユーザーから問題の報告がなければ、徐々に範囲を拡大し、最終的に全ユーザーに新バージョンの機能を開放する。カナリアリリースはシステム全体の安定性を確保でき、初期のカナリア段階で問題を発見・修正し、影響範囲を抑えることができる。
- ロールバック
プログラムまたはデータの処理に誤りがあった場合に、プログラムやデータを前回の正しい状態（または前の安定バージョン）に戻す動作を指す。