高可用性Web開発戦略｜止まらないシステム設計の考え方を解説

Webサービスは、ユーザーがいつでも利用できることが前提になっています。ECサイト、予約システム、SaaS、金融系サービス、業務システム、メディアサイト、API基盤などでは、数分の停止でも売上損失、信用低下、問い合わせ増加、業務停止につながることがあります。そのため、Web開発では機能を作るだけでなく、障害が発生してもサービスを継続できる高可用性の考え方が重要になります。

高可用性は、単なるインフラ構成の問題ではありません。アプリケーション設計、データベース設計、クラウド構成、負荷分散、監視、ログ、デプロイ、障害対応、SRE、運用体制まで関係します。止まらないシステムを作るには、障害が起きない前提ではなく、障害は必ず起きる前提で設計する必要があります。本記事では、高可用性Web開発戦略を、冗長化、HA構成、負荷分散、クラウド、データ設計、監視、障害対応、SREまで体系的に解説します。

1. 高可用性とは？

高可用性とは、システムが継続して利用できる状態を維持するための設計思想です。Webサービスでは、サーバー、データベース、ネットワーク、外部API、ストレージ、アプリケーションなど、さまざまな構成要素が関係します。どこか一部に障害が起きても、サービス全体が停止しないようにすることが高可用性の基本です。

高可用性は、稼働率やダウンタイムといった指標で評価されます。ただし、数値だけを追うのではなく、ユーザーにとって利用できる状態が維持されているかが重要です。画面が表示されてもログインできない、購入できない、APIが極端に遅い場合は、実質的には可用性が低い状態といえます。

1.1 システムを止めない設計思想

高可用性は、システムを止めないための設計思想です。単一のサーバーにすべてを依存している場合、そのサーバーが停止するとサービス全体が止まります。高可用性を意識したWeb開発では、複数サーバー構成、ロードバランサー、レプリケーション、フェイルオーバー、クラウドのマルチAZ構成などを活用し、一部障害が全体停止につながらないようにします。

ただし、完全に止まらないシステムを作ることは現実的ではありません。重要なのは、停止リスクを下げ、障害発生時の影響範囲を小さくし、復旧時間を短縮することです。高可用性Web開発では、障害を完全に排除するよりも、障害が起きてもサービスを継続できる構造を作ることが重要です。

1.2 障害前提で構築する

高可用性では、障害が発生する前提で構築します。サーバーは落ちる可能性があり、DBは遅延する可能性があり、クラウドサービスにも一時的な障害が起こる可能性があります。外部API、DNS、CDN、ネットワーク、デプロイミス、セキュリティ攻撃なども可用性に影響します。

障害前提で構築するには、冗長化、監視、ログ、リトライ、タイムアウト、サーキットブレーカー、フェイルオーバー、バックアップ、復旧手順を設計へ含めます。正常に動く機能だけでなく、異常時にどのように動くかを設計することが、高可用性Web開発の基本になります。

1.3 可用性はビジネス指標にもなる

可用性は、技術指標であると同時にビジネス指標でもあります。ECサイトが停止すれば売上機会を失い、SaaSが停止すれば顧客業務に影響します。予約システムや決済システムでは、短時間の停止でもユーザー離脱や信用低下につながることがあります。高可用性は、ユーザー体験と事業継続に直結します。

そのため、すべてのシステムで同じレベルの可用性を目指す必要はありません。事業への影響、ユーザー数、収益性、法的要件、復旧許容時間を考慮して、適切な可用性レベルを決めることが重要です。高可用性は、技術的に高い構成を作ることではなく、ビジネスに必要な信頼性を実現することです。

2. 冗長化設計

冗長化設計は、高可用性Web開発の基本です。冗長化とは、同じ役割を持つ構成要素を複数用意し、一部が故障してもサービスを継続できるようにすることです。Webサーバー、アプリケーションサーバー、データベース、キャッシュ、ネットワーク、ストレージなど、重要な箇所には冗長化を検討します。

冗長化は、単にサーバーを増やせばよいわけではありません。ロードバランサーによる振り分け、ヘルスチェック、フェイルオーバー、データ同期、セッション管理、ログ統合なども必要です。冗長化したつもりでも、実際には単一障害点が残っているケースは多いため、構成全体を見直すことが重要です。

2.1 サーバーを複数構成にする

Webサービスで最初に考える冗長化は、サーバーを複数構成にすることです。1台のアプリケーションサーバーだけで運用している場合、そのサーバーに障害が発生するとサービスが停止します。複数台のサーバーを用意し、ロードバランサーでアクセスを分散すれば、1台が停止しても他のサーバーで処理を継続できます。

複数サーバー構成では、アプリケーションをステートレスにすることが重要です。ユーザーセッションや一時ファイルを特定サーバーに保存していると、別サーバーへ切り替わったときに状態が失われる可能性があります。セッションは共有ストアやトークンで管理し、ファイルは外部ストレージへ保存するなど、水平スケールしやすい構成にする必要があります。

2.2 単一障害点を排除する

高可用性を実現するには、単一障害点を排除する必要があります。単一障害点とは、そこが止まるとシステム全体が止まる箇所です。アプリケーションサーバーを複数台にしても、ロードバランサーが1台だけ、DBが1台だけ、NATやDNSが冗長化されていない場合、そこが障害点になります。

単一障害点を見つけるには、システム全体の構成図を作り、リクエストの流れを追うことが有効です。ユーザーからのアクセスがどのコンポーネントを通り、どこでデータを読み書きし、どの外部サービスに依存しているのかを整理します。高可用性Web開発では、目立つサーバーだけでなく、周辺サービスや運用ツールまで含めて障害点を確認することが重要です。

2.3 フェイルオーバーを設計する

冗長化では、フェイルオーバー設計が必要です。フェイルオーバーとは、障害が発生したときに、正常な別系統へ自動または手動で切り替える仕組みです。Webサーバーであればロードバランサーが異常なインスタンスを切り離し、DBであれば待機系へ切り替えるなどの設計が考えられます。

フェイルオーバーは、仕組みを用意するだけでなく、実際に動作するか検証することが重要です。切り替えに何秒かかるのか、切り替え中にデータ不整合が起きないか、アプリケーションが接続先変更に対応できるかを確認する必要があります。高可用性では、障害時に本当に切り替わることをテストする姿勢が大切です。

3. 負荷分散（ロードバランシング）

負荷分散は、高可用性とスケーラビリティの両方に関係します。ロードバランサーを使うことで、ユーザーからのリクエストを複数のサーバーへ分散し、1台のサーバーに負荷が集中することを防げます。また、異常なサーバーをヘルスチェックで検知し、振り分け対象から外すことで可用性を高められます。

負荷分散は、単なるトラフィック分散ではありません。L4とL7の違い、セッション維持、SSL終端、ヘルスチェック、スパイクアクセス対応、オートスケール連携なども考える必要があります。Web開発では、アプリケーション構成と負荷分散方式をセットで設計することが重要です。

3.1 トラフィックを分散する

ロードバランサーは、ユーザーからのトラフィックを複数のサーバーへ分散します。アクセスが増えても、複数台で処理できるため、1台あたりの負荷を下げられます。Webサービスでは、アプリケーションサーバーを複数台構成にし、ロードバランサー経由でアクセスさせる構成が一般的です。

トラフィック分散では、ヘルスチェックが重要です。サーバーが応答しない、エラー率が高い、CPUやメモリが異常な状態になった場合、ロードバランサーがそのサーバーへ振り分け続けると障害が拡大します。正常なサーバーだけへリクエストを送る仕組みが、高可用性には不可欠です。

3.2 L4/L7バランシングを使う

ロードバランシングには、L4とL7の考え方があります。L4ロードバランシングは、TCPやUDPなどのトランスポート層で振り分ける方式です。一方、L7ロードバランシングは、HTTPリクエストのパス、ヘッダー、ホスト名などを見て振り分けられます。Webサービスでは、L7を使うことで柔軟なルーティングが可能になります。

たとえば、APIリクエストはAPIサーバーへ、画像関連は別サービスへ、管理画面は専用サーバーへ振り分けるといった構成ができます。L7ロードバランサーは便利ですが、設定が複雑になることもあります。高可用性Web開発では、用途に応じてL4とL7を使い分け、構成を過度に複雑化しないことが大切です。

3.3 スパイクアクセスに対応する

Webサービスでは、突然アクセスが増えるスパイクが発生することがあります。キャンペーン、SNS拡散、テレビ紹介、障害復旧後の集中アクセス、セール開始などが原因です。スパイクに対応できないと、サーバー負荷が急上昇し、レスポンス遅延やサービス停止につながります。

スパイクアクセスへ対応するには、ロードバランサー、オートスケーリング、キャッシュ、CDN、Queue、レート制限を組み合わせます。特に、読み取り中心のページはキャッシュやCDNで吸収し、書き込み処理はQueueで平準化する設計が有効です。高可用性では、通常時だけでなく急激な負荷増加にも耐えられる構成が必要です。

4. スケーラビリティ設計

スケーラビリティ設計は、高可用性Web開発において重要です。アクセス数やデータ量が増えたときに、システムを拡張できる構造でなければ、成長とともに障害リスクが高まります。スケーラビリティが不足していると、高負荷時にレスポンスが遅くなり、最終的にはサービス停止につながることがあります。

スケーラビリティは、アプリケーション、DB、キャッシュ、ストレージ、ネットワーク、監視、デプロイすべてに関係します。最初から大規模な構成にする必要はありませんが、将来的に水平スケールしやすい設計を意識することが重要です。

4.1 水平スケールを前提にする

高可用性Web開発では、水平スケールを前提にすることが重要です。水平スケールとは、サーバーの性能を上げるのではなく、サーバー台数を増やして処理能力を高める方法です。クラウド環境では、複数インスタンスを追加し、ロードバランサーで分散する構成が一般的です。

水平スケールするには、アプリケーションをステートレスにする必要があります。サーバーごとに状態を持っていると、どのサーバーにアクセスするかで挙動が変わる可能性があります。セッション、ファイル、キャッシュ、ジョブ状態を外部管理し、どのサーバーでも同じ処理ができる構造にすることが重要です。

4.2 Auto Scalingを活用する

Auto Scalingは、負荷に応じてサーバー台数を自動的に増減させる仕組みです。アクセスが増えたときにインスタンスを増やし、負荷が下がったら減らすことで、可用性とコスト効率を両立できます。クラウド環境では、高可用性Web開発において重要な機能です。

ただし、Auto Scalingを導入すれば自動的に高可用性になるわけではありません。起動時間、ヘルスチェック、デプロイ方式、DB接続数、キャッシュウォームアップなどを考慮する必要があります。急激なスパイクではインスタンス追加が間に合わないこともあるため、キャッシュやCDNとの組み合わせが重要です。

4.3 将来負荷を想定する

スケーラビリティ設計では、将来負荷を想定することが大切です。現在のアクセス数だけを基準にすると、成長後にボトルネックが発生しやすくなります。ユーザー数、同時接続数、データ量、画像や動画の容量、APIリクエスト数、バッチ処理量がどの程度増えるかを考える必要があります。

将来負荷を想定することで、DB設計、キャッシュ戦略、ストレージ構成、Queue設計、ログ基盤の選択が変わります。過剰設計は避けるべきですが、拡張できない設計は長期的なリスクになります。高可用性Web開発では、現在と将来の両方を見据えた現実的なスケール設計が重要です。

5. データベース高可用性

データベースは、高可用性Web開発における最大のボトルネックになりやすい部分です。アプリケーションサーバーは比較的簡単に複数台構成にできますが、DBはデータの整合性、書き込み、レプリケーション、フェイルオーバー、バックアップが関係するため、設計が難しくなります。

DBが停止すると、ログイン、注文、投稿、検索、管理操作など、多くの機能が利用できなくなる可能性があります。高可用性を考える場合、アプリケーションだけでなく、DBの冗長化と復旧設計を必ず検討する必要があります。

5.1 レプリケーションを構成する

DBの高可用性では、レプリケーションが重要です。レプリケーションとは、プライマリDBのデータをレプリカDBへ複製する仕組みです。プライマリに障害が発生した場合、レプリカを昇格させてサービスを継続できるようにします。また、読み取り処理をレプリカへ分散することで、プライマリの負荷を下げることもできます。

レプリケーションでは、同期方式と遅延に注意が必要です。非同期レプリケーションでは、障害時に一部データが失われる可能性があります。同期レプリケーションは整合性を高められますが、書き込み性能に影響する場合があります。高可用性Web開発では、データ損失許容度と性能のバランスを考えてレプリケーション方式を選ぶ必要があります。

5.2 マスター障害に備える

プライマリDB、つまり書き込みを担当するマスターに障害が起きると、サービスへの影響は大きくなります。読み取りはレプリカで継続できても、書き込みができなければ注文、登録、更新、決済処理などが止まります。そのため、マスター障害に備えたフェイルオーバー設計が不可欠です。

マスター障害に備えるには、自動フェイルオーバー、接続先切り替え、昇格手順、アプリケーションの再接続処理を設計します。フェイルオーバー中に書き込みが失敗した場合のリトライやエラー表示も必要です。DBフェイルオーバーは複雑なため、定期的に切り替えテストを行うことが重要です。

5.3 読み取り分離を行う

読み取り分離は、DB負荷を軽減し、高可用性を高めるために有効です。参照系のクエリをリードレプリカへ流し、書き込みはプライマリへ集約することで、プライマリDBの負荷を下げられます。メディアサイト、ECサイト、SaaSダッシュボードなど、読み取りが多いサービスでは効果的です。

ただし、読み取り分離ではレプリケーション遅延に注意が必要です。ユーザーがデータを更新した直後にレプリカから読み取ると、古い情報が表示される可能性があります。重要な更新直後はプライマリから読む、遅延を許容できる画面だけレプリカを使うなど、整合性要件に応じた設計が必要です。

6. キャッシュ戦略

キャッシュ戦略は、高可用性とパフォーマンス改善に大きく貢献します。DBや外部APIへのアクセスを減らし、レスポンスを高速化することで、高負荷時でもサービスを安定させやすくなります。RedisやMemcachedなどのインメモリストア、CDNキャッシュ、アプリケーションキャッシュなどが代表的です。

キャッシュは強力ですが、設計を誤ると古いデータ表示や不整合の原因になります。何をキャッシュし、どのタイミングで更新し、どのように破棄するかを決めることが重要です。高可用性Web開発では、キャッシュを単なる高速化手段ではなく、負荷吸収と障害耐性を高める仕組みとして考える必要があります。

6.1 Redisなどを活用する

Redisなどのインメモリデータストアは、キャッシュ、セッション管理、レート制限、Queue、ランキングなどに活用できます。DBより高速に読み書きできるため、頻繁に参照されるデータをキャッシュすることで、DB負荷を大きく下げられます。高トラフィックのWebサービスでは、Redis活用が可用性向上に役立ちます。

ただし、Redis自体が単一障害点にならないように注意が必要です。Redisが停止すると、セッションが消える、キャッシュミスが急増する、Queueが止まるといった問題が起こります。Redisを重要なコンポーネントとして利用する場合は、冗長化、永続化、監視、メモリ管理を設計へ含める必要があります。

6.2 DB負荷を軽減する

キャッシュの大きな目的は、DB負荷を軽減することです。人気ページ、商品情報、設定情報、ランキング、カテゴリ一覧、ユーザープロフィールなど、頻繁に読まれるが更新頻度が低いデータはキャッシュに向いています。DBへのクエリ数を減らすことで、ピーク時の負荷を抑えられます。

ただし、キャッシュが切れたタイミングで大量アクセスがDBへ集中するキャッシュスタンピードには注意が必要です。期限を分散する、ロックを使う、バックグラウンド更新するなどの対策が必要です。高可用性Web開発では、キャッシュ導入後の失効タイミングや負荷集中まで考えることが重要です。

6.3 レスポンスを高速化する

キャッシュは、レスポンス高速化にも有効です。ユーザーがアクセスするたびにDBや外部APIへ問い合わせるのではなく、キャッシュ済みデータを返せば、応答時間を短縮できます。応答が速いサービスは、ユーザー体験が良くなるだけでなく、サーバー負荷も軽くなります。

レスポンス高速化では、どの層でキャッシュするかを考える必要があります。ブラウザキャッシュ、CDNキャッシュ、アプリケーションキャッシュ、DBクエリキャッシュなど、複数の層があります。高可用性Web開発では、データの鮮度と速度のバランスを考え、適切なキャッシュ層を選ぶことが大切です。

7. CDN活用

CDNは、静的コンテンツを世界中の配信拠点からユーザーへ届ける仕組みです。画像、CSS、JavaScript、動画、フォント、静的HTMLなどをCDNで配信することで、オリジンサーバーへの負荷を減らし、ユーザーに近い場所から高速に配信できます。高可用性Web開発では、CDN活用が非常に重要です。

CDNは、パフォーマンス改善だけでなく、可用性向上にも役立ちます。オリジンサーバーへのアクセス集中を避け、静的コンテンツの配信を分散できます。また、一部CDNにはDDoS対策やWAF機能もあり、セキュリティ面でも有効です。

7.1 静的コンテンツを分散配信する

CDNを使うと、静的コンテンツを分散配信できます。画像、CSS、JavaScript、商品画像、動画サムネイル、ダウンロードファイルなどをCDNへ配置すれば、ユーザーは近いエッジサーバーからファイルを取得できます。これにより、アプリケーションサーバーの負荷を大きく減らせます。

静的コンテンツの配信をオリジンサーバーに集中させると、アクセス増加時にサーバー負荷が高まり、動的処理にも影響が出ることがあります。CDNを活用すれば、静的配信と動的処理を分離でき、Webサービス全体の安定性が高まります。

7.2 レイテンシを削減する

CDNは、ユーザーとの距離を短くすることでレイテンシを削減します。特に、全国またはグローバルにユーザーがいるWebサービスでは、オリジンサーバーが1地域にしかないと、遠隔地のユーザーは読み込みが遅くなります。CDNを使えば、各地域のエッジ拠点から配信できるため、表示速度を改善できます。

レイテンシ削減は、ユーザー体験だけでなく可用性にも関係します。応答が遅すぎるサービスは、ユーザーにとって利用できない状態に近くなります。高可用性Web開発では、システムが落ちないことだけでなく、十分な速度で応答することも重要です。

7.3 グローバル対応を強化する

グローバル向けWebサービスでは、CDNの活用が特に重要です。日本、北米、欧州、アジアなど、ユーザーが複数地域に分散している場合、単一リージョンからの配信では遅延が大きくなります。CDNを使うことで、地域ごとの配信品質を安定させられます。

グローバル対応では、静的コンテンツだけでなく、APIレイテンシ、DB配置、認証、言語切り替え、法規制対応も関係します。CDNはその中の重要な要素ですが、全体設計の一部として考えることが必要です。高可用性では、利用地域に応じた配信戦略を設計することが大切です。

8. 障害検知と監視

高可用性を実現するには、障害を早期に検知する監視が欠かせません。システムが停止してからユーザーの問い合わせで気づく状態では、復旧が遅れ、ビジネス影響も大きくなります。監視によって、エラー率、レスポンスタイム、CPU、メモリ、DB負荷、Queue滞留、外部API障害を把握する必要があります。

監視は、導入するだけでは不十分です。何を監視し、どの閾値でアラートを出し、誰が対応し、どの手順で復旧するかまで設計することが重要です。高可用性Web開発では、監視と障害対応を一体で考える必要があります。

8.1 メトリクスを収集する

メトリクスとは、システム状態を数値化したデータです。CPU使用率、メモリ使用量、ディスク使用量、DB接続数、レスポンスタイム、リクエスト数、エラー率、スループットなどが代表的です。これらを継続的に収集することで、システムの健康状態を把握できます。

メトリクス収集では、インフラだけでなくアプリケーションの指標も重要です。ログイン成功率、決済失敗率、APIエラー率、ジョブ失敗数、通知遅延など、ユーザー体験に近い指標を監視することで、実際のサービス品質を把握しやすくなります。高可用性では、技術指標とビジネス影響の両方を見ることが大切です。

8.2 アラートを設定する

監視データを収集しても、異常時に通知されなければ意味がありません。アラートを設定し、障害や異常兆候を早期に担当者へ知らせる必要があります。CPU使用率やエラー率だけでなく、レスポンスタイム悪化、DBレプリケーション遅延、Queue滞留、外部API失敗率などもアラート対象になります。

アラート設計では、通知しすぎに注意が必要です。不要なアラートが多いと、担当者が通知に慣れてしまい、本当に重要な障害を見落とす可能性があります。高可用性Web開発では、重要度に応じたアラート設計、通知先、エスカレーション、抑制ルールを整えることが重要です。

8.3 異常を早期発見する

高可用性では、完全停止する前に異常を早期発見することが重要です。レスポンスが少しずつ遅くなる、エラー率が増える、DB接続が増え続ける、メモリ使用量が解放されないなど、障害には前兆があることがあります。これらを早く検知できれば、停止前に対応できます。

異常の早期発見には、ベースラインの把握が必要です。通常時の負荷やレスポンスタイムを知らなければ、異常値を判断できません。高可用性Web開発では、通常状態を可視化し、そこからの変化を検知する監視設計が重要です。

9. ログ設計

ログ設計は、障害対応と高可用性において重要です。障害が発生したとき、ログがなければ原因を特定できません。どのリクエストでエラーが起きたのか、どのユーザー操作が失敗したのか、どの外部APIが遅延したのかを追跡できるようにする必要があります。

分散構成のWebサービスでは、複数サーバー、複数コンテナ、複数サービスにログが分散します。そのため、ログを統合し、検索しやすく、相関IDで追跡できるようにすることが重要です。ログ設計は、障害後に慌てて整えるものではなく、開発初期から考えるべき要素です。

9.1 分散ログを統合する

マイクロサービスや複数サーバー構成では、ログが各所に分散します。アプリケーションログ、Webサーバーログ、DBログ、ロードバランサーログ、コンテナログ、クラウド監査ログなどが別々に保存されていると、障害調査に時間がかかります。分散ログを統合することで、問題の流れを追いやすくなります。

ログ統合では、ログの形式を揃えることも重要です。タイムスタンプ、リクエストID、ユーザーID、エラーコード、処理時間、サービス名などを構造化して記録すれば、検索や分析がしやすくなります。高可用性Web開発では、障害時に必要な情報をすぐ取り出せるログ基盤が必要です。

9.2 障害解析を可能にする

ログは、障害解析を可能にするための重要な情報源です。単に「エラーが発生しました」と記録するだけでは不十分です。どの処理で、どの入力に対して、どの外部サービスが、どの例外を返したのかを確認できる必要があります。障害解析に使えるログを残すことが重要です。

ただし、ログに個人情報や機密情報を残しすぎるのは危険です。メールアドレス、住所、決済情報、認証トークンなどをそのままログに出力すると、情報漏えいリスクが高まります。高可用性とセキュリティを両立するためには、必要な情報を構造化しつつ、機密情報はマスキングする設計が必要です。

9.3 トレースを残す

分散システムでは、トレースを残すことが重要です。1つのユーザーリクエストが、ロードバランサー、APIサーバー、認証サービス、DB、外部API、Queueを通る場合、どこで遅延やエラーが発生したのかを追跡する必要があります。トレースIDを使えば、複数サービスにまたがる処理の流れを確認できます。

トレースを残すことで、パフォーマンス問題の原因も見つけやすくなります。どのAPIが遅いのか、DBクエリが重いのか、外部API待ちなのかを可視化できます。高可用性Web開発では、ログ、メトリクス、トレースを組み合わせてシステムを観測可能にすることが重要です。

10. フェイルオーバー設計

フェイルオーバー設計は、高可用性を実現するうえで重要です。フェイルオーバーとは、障害が発生したときに、正常な系統へ処理を切り替えることです。Webサーバー、DB、キャッシュ、ストレージ、ネットワーク、リージョンなど、さまざまな層でフェイルオーバーを考える必要があります。

フェイルオーバーは、自動化できる部分と手動判断が必要な部分があります。自動化すれば復旧は早くなりますが、誤検知による切り替えやデータ不整合のリスクもあります。高可用性Web開発では、切り替えの条件、手順、影響、復旧後の戻し方まで設計することが大切です。

10.1 自動切り替えを実装する

自動切り替えを実装すると、障害発生時の復旧時間を短縮できます。ロードバランサーが異常なサーバーを切り離す、DBクラスタが待機系へ切り替える、DNSやトラフィックルーティングで別リージョンへ誘導するなどの方法があります。ユーザー影響を最小化するには、自動化が有効です。

ただし、自動切り替えは慎重に設計する必要があります。短時間の一時的な遅延で不要な切り替えが発生すると、かえって障害を広げる場合があります。ヘルスチェック条件、切り替え閾値、復帰条件、通知を適切に設定し、自動化の範囲を明確にすることが重要です。

10.2 冗長リージョンを用意する

大規模または重要度の高いWebサービスでは、冗長リージョンを用意することがあります。単一リージョンに依存していると、その地域のクラウド障害やネットワーク障害の影響を受けます。複数リージョン構成にすれば、1つのリージョンが停止しても別リージョンでサービスを継続できる可能性があります。

ただし、マルチリージョン構成はコストと複雑性が高くなります。データ同期、DNS切り替え、レイテンシ、整合性、運用手順を考える必要があります。すべてのサービスで必要なわけではないため、事業影響や復旧要件に応じて判断することが重要です。

10.3 ダウンタイムを最小化する

フェイルオーバー設計の目的は、ダウンタイムを最小化することです。障害が起きても、ユーザーが利用できない時間を短くし、影響範囲を限定することが求められます。RTO、つまり復旧までに許容される時間を決めておくと、設計判断がしやすくなります。

ダウンタイムを最小化するには、切り替え自動化、冗長構成、データ同期、監視、復旧手順が必要です。また、フェイルオーバー後にサービスが正常に動作しているかを確認するチェックも重要です。高可用性では、切り替えることだけでなく、切り替え後に正しく運用できることが大切です。

11. 障害対応設計

障害対応設計は、高可用性の一部です。どれだけ冗長化しても、障害は完全には避けられません。重要なのは、障害が起きたときに素早く検知し、影響を把握し、復旧し、再発防止につなげることです。障害対応は、技術だけでなく組織的な運用も含みます。

障害対応設計では、対応フロー、担当者、連絡手段、復旧手順、エスカレーション、ユーザー告知、事後分析を決めておく必要があります。障害が起きてから考えると判断が遅れるため、事前に運用ルールを整備することが重要です。

11.1 障害発生時のフローを定義する

障害発生時のフローを定義しておくことで、対応の初動が早くなります。アラートを受けたら誰が確認するのか、影響範囲をどう判断するのか、どのチャンネルで連絡するのか、誰が意思決定するのかを明確にします。フローが曖昧だと、対応が遅れ、影響が拡大します。

障害対応フローには、一次対応、原因調査、暫定復旧、恒久対応、ユーザー通知、事後レビューを含めるとよいです。高可用性Web開発では、システム構成だけでなく、障害時に人がどう動くかまで設計に含める必要があります。

11.2 復旧手順を整備する

復旧手順を整備しておくことは、障害対応で非常に重要です。DBフェイルオーバー、ロールバック、キャッシュ削除、サーバー再起動、Queue再処理、設定戻しなど、障害時に必要な操作は事前に手順化しておくべきです。手順がないと、緊急時に判断ミスが起こりやすくなります。

復旧手順は、実際に使える形で管理する必要があります。古い手順書や実行できないコマンドが残っていると、障害時に役に立ちません。定期的に手順を見直し、訓練やリハーサルを行うことで、実効性を保つことが重要です。

11.3 インシデント管理を行う

高可用性を高めるには、インシデント管理が必要です。障害が発生したら、発生時刻、影響範囲、原因、対応内容、復旧時刻、再発防止策を記録します。インシデントを記録することで、同じ障害を繰り返さないための改善につなげられます。

インシデント管理では、責任追及よりも学習を重視することが重要です。誰が失敗したかではなく、なぜその障害が起きたのか、なぜ検知が遅れたのか、なぜ影響が広がったのかを分析します。高可用性Web開発では、障害から学び、システムと運用を継続的に改善する姿勢が必要です。

12. セキュリティと可用性

セキュリティは可用性にも大きく関係します。DDoS攻撃、脆弱性攻撃、不正アクセス、Botアクセス、WAF設定ミスなどは、サービス停止やパフォーマンス低下につながる可能性があります。高可用性Web開発では、攻撃によってシステムが利用できなくなるリスクも考慮する必要があります。

可用性を守るためのセキュリティ対策には、DDoS対策、WAF、レート制限、Bot対策、認証強化、脆弱性管理、監視があります。セキュリティと可用性は別々のテーマではなく、信頼性設計の一部として扱うことが重要です。

12.1 DDoS対策を行う

DDoS攻撃は、大量のリクエストを送りつけてサービスを停止させる攻撃です。WebサービスがDDoS攻撃を受けると、サーバーやネットワークが処理しきれず、正規ユーザーがアクセスできなくなる可能性があります。高可用性を考えるうえで、DDoS対策は重要です。

DDoS対策には、CDN、クラウドDDoS保護、レート制限、トラフィックフィルタリング、WAF、オートスケールが有効です。ただし、アプリケーション層への攻撃では、単純な帯域対策だけでは不十分な場合があります。高可用性Web開発では、攻撃パターンに応じた多層防御が必要です。

12.2 WAFを導入する

WAFは、Webアプリケーションへの攻撃を検知・遮断する仕組みです。SQLインジェクション、クロスサイトスクリプティング、不正なリクエスト、脆弱性を狙った攻撃などからWebサービスを守るために利用されます。WAFを導入することで、アプリケーションの可用性と安全性を高められます。

ただし、WAFの設定が強すぎると、正規ユーザーのリクエストまで遮断する可能性があります。逆に、設定が緩すぎると攻撃を防げません。WAFは導入して終わりではなく、ログ確認、ルール調整、誤検知対応を継続的に行うことが重要です。

12.3 攻撃耐性を高める

攻撃耐性を高めるには、アプリケーション、インフラ、ネットワーク、運用の各層で対策を行う必要があります。入力検証、認証、認可、レート制限、監査ログ、脆弱性対応、依存ライブラリ更新などが重要です。攻撃によってサーバー負荷が高まる場合もあるため、セキュリティ対策は可用性対策にもなります。

また、攻撃を完全に防ぐだけでなく、攻撃中でも重要機能を維持する設計が必要です。重要APIへの保護、優先制御、キャッシュ利用、管理機能の分離などを検討します。高可用性Web開発では、セキュリティインシデント時にもサービス影響を最小化する考え方が重要です。

13. デプロイ戦略

デプロイ戦略は、高可用性に大きく影響します。新しいコードをリリースするときにサービス停止が発生したり、不具合が本番に反映されたりすると、可用性が低下します。高可用性Web開発では、リリース時のリスクを減らすデプロイ方式が重要です。

代表的なデプロイ戦略には、Blue-Green Deployment、Rolling Update、Canary Release、Feature Flagなどがあります。どの方式を選ぶかは、サービス規模、リリース頻度、インフラ構成、ロールバック要件によって変わります。

13.1 Blue-Green Deploymentを使う

Blue-Green Deploymentは、本番環境と同等の環境を2つ用意し、新バージョンを片方にデプロイしてからトラフィックを切り替える方式です。問題が発生した場合は、旧環境へ戻すことで素早くロールバックできます。サービス停止を最小化しやすい点がメリットです。

ただし、Blue-Green Deploymentでは、環境を2つ維持するためコストが増えます。また、DBスキーマ変更がある場合は、旧バージョンと新バージョンの互換性を考える必要があります。高可用性Web開発では、アプリケーションだけでなくデータ構造の変更も含めてデプロイ戦略を考えることが重要です。

13.2 Rolling Updateを行う

Rolling Updateは、複数台あるサーバーを順番に更新していく方式です。一部のサーバーを新バージョンへ切り替え、正常性を確認しながら段階的に更新します。すべてのサーバーを一度に止めないため、サービスを継続しながらデプロイできます。

Rolling Updateでは、新旧バージョンが一時的に同時稼働することがあります。そのため、APIやDBスキーマに互換性が必要です。セッション管理やキャッシュ構造も、新旧バージョンで問題が起きないように設計する必要があります。可用性を保つには、リリース方式とアプリケーション設計を連動させることが大切です。

13.3 ロールバックを準備する

高可用性を維持するには、ロールバックを準備しておくことが重要です。リリース後に不具合が発覚した場合、迅速に前の状態へ戻せなければ、障害時間が長くなります。アプリケーションコード、設定、DB変更、インフラ変更、それぞれのロールバック手順を考える必要があります。

特にDBマイグレーションは注意が必要です。一度データ構造を変更すると、単純にアプリケーションだけを戻しても動かない場合があります。ロールバック可能な変更設計、段階的マイグレーション、Feature Flagの活用が有効です。高可用性Web開発では、リリースすることだけでなく、戻せることも設計に含める必要があります。

14. SRE視点

SREは、Site Reliability Engineeringの略で、システムの信頼性をソフトウェアエンジニアリングの考え方で高める取り組みです。高可用性Web開発では、SREの視点が重要になります。単に障害を減らすだけでなく、信頼性を数値化し、開発速度と安定性のバランスを取る考え方が求められます。

SREでは、SLO、SLI、エラーバジェットなどの概念を使います。すべてを完璧に止めないことを目指すのではなく、ユーザーにとって必要な信頼性を定義し、その範囲内で開発と改善を進めます。高可用性を現実的に運用するための考え方として重要です。

14.1 SLO/SLIを定義する

SLIは、サービスレベル指標です。たとえば、リクエスト成功率、レスポンスタイム、エラー率、可用性、レイテンシなどが該当します。SLOは、SLIに対する目標値です。たとえば、月間リクエストの99.9%を正常応答にする、95%のAPIを300ms以内に返すといった形で定義します。

SLOとSLIを定義することで、信頼性を感覚ではなく数値で扱えます。すべての指標を監視するのではなく、ユーザー体験に直結する指標を選ぶことが重要です。高可用性Web開発では、技術的な稼働状態よりも、ユーザーがサービスを利用できているかを重視する必要があります。

14.2 エラーバジェットを管理する

エラーバジェットは、許容できる障害やエラーの余地を表す考え方です。たとえば、SLOを99.9%に設定した場合、残りの0.1%は許容されるエラーやダウンタイムとして扱えます。この範囲内であれば、新機能リリースや改善を進め、超過しそうなら信頼性改善を優先します。

エラーバジェットを使うことで、開発速度と信頼性のバランスを取りやすくなります。可用性を100%に近づけようとするとコストが大きくなりますが、事業に必要な目標を定義すれば、現実的な判断ができます。高可用性では、過剰な安定性を追うのではなく、必要な信頼性を明確にすることが重要です。

14.3 信頼性を数値化する

SRE視点では、信頼性を数値化することが重要です。感覚的に「最近よく落ちる」「遅い気がする」と判断するのではなく、エラー率、レスポンスタイム、成功率、障害時間、復旧時間を数値で確認します。数値化することで、改善の優先順位を決めやすくなります。

信頼性を数値化すると、ビジネス側とのコミュニケーションもしやすくなります。どのレベルの可用性が必要で、そのためにどれだけコストがかかるのかを説明できます。高可用性Web開発では、技術とビジネスの両方が納得できる指標設計が重要です。

15. よくある高可用性の失敗

高可用性を目指していても、実際には多くの失敗が起こります。サーバーは冗長化しているがDBが単一構成、監視はあるがアラートが機能していない、フェイルオーバーを一度も試していない、スケール設計が不足しているといったケースです。見た目だけのHA構成では、障害時に機能しないことがあります。

よくある失敗を理解しておくことで、設計段階から対策できます。高可用性は構成図だけで成立するものではなく、実際に障害が起きたときに動作することが重要です。

15.1 単一障害点が残る

高可用性構成でよくある失敗は、単一障害点が残っていることです。アプリケーションサーバーは複数台あるのに、DB、ロードバランサー、ストレージ、DNS、キャッシュ、外部APIが単一障害点になっている場合があります。一部が止まるだけで全体停止につながる構成は、高可用性とはいえません。

単一障害点を排除するには、システム全体を俯瞰する必要があります。ユーザーリクエストの経路、データ保存先、認証基盤、外部連携、管理機能まで確認します。高可用性Web開発では、目立つサーバーだけでなく、依存関係すべてを確認することが大切です。

15.2 監視が不十分

監視が不十分なシステムでは、障害発生に気づくのが遅れます。サーバーが落ちてからユーザー問い合わせで気づく、エラー率が上がっているのに通知されない、DB遅延に気づかないといった状態は危険です。監視がなければ、可用性を維持することは難しくなります。

監視では、インフラ指標だけでなく、ユーザー体験に近い指標も見る必要があります。ページが表示できるか、ログインできるか、決済できるか、APIが正常応答しているかを監視します。高可用性では、システムが動いているかではなく、サービスとして使えるかを監視することが重要です。

15.3 スケール設計不足

スケール設計不足もよくある失敗です。通常時は問題なく動いていても、アクセス集中時にサーバーやDBが耐えられず、レスポンス遅延や停止が発生します。スケール設計が不足していると、サービス成長そのものが障害リスクになります。

スケール設計では、水平スケール、キャッシュ、CDN、DB最適化、Queue、オートスケールを検討します。特に、どの処理が増えやすいのかを理解することが重要です。高可用性Web開発では、現在の負荷だけでなく、成長やスパイクを想定する必要があります。

15.4 DBがボトルネックになる

DBがボトルネックになるケースは非常に多いです。アプリケーションサーバーを増やしても、DBが1台で処理しきれなければ全体の性能は上がりません。重いクエリ、インデックス不足、接続数不足、書き込み集中、ロック競合などが原因になります。

DBボトルネックを防ぐには、クエリ最適化、インデックス設計、読み取り分離、キャッシュ、非同期処理、データ分割を検討します。DBは状態を持つため、スケールが難しい部分です。高可用性Web開発では、DB設計を初期段階から慎重に考えることが重要です。

15.5 フェイルオーバー未検証

フェイルオーバー機能を用意していても、一度も検証していない場合、本番障害時に動かない可能性があります。切り替え先が正しく起動しない、DNS反映が遅い、アプリケーションが再接続できない、データ同期が遅れているなど、実際に試さなければ分からない問題があります。

フェイルオーバーは、定期的にテストすることが重要です。メンテナンス時間や検証環境で切り替え訓練を行い、手順と所要時間を確認します。高可用性では、構成を作るだけでなく、障害時に本当に機能することを確認する必要があります。

16. 運用フェーズの重要性

高可用性は、開発時の設計だけでは維持できません。運用フェーズでの監視、負荷テスト、障害訓練、改善活動が重要です。サービスはリリース後にユーザー数が増え、機能が追加され、データ量が増え、依存サービスも変化します。そのため、可用性も継続的に見直す必要があります。

運用フェーズでは、実際の障害や負荷状況から学ぶことができます。設計時の想定と現実の使われ方が異なることも多いため、監視データやログをもとに継続改善を行うことが重要です。

16.1 継続監視を行う

継続監視は、高可用性運用の基本です。リリース直後だけでなく、日常的にメトリクス、ログ、トレース、エラー率、レスポンスタイムを確認します。異常が発生したときにすぐ検知できる体制を作ることが重要です。

継続監視では、アラートの品質も改善していく必要があります。不要な通知が多い場合は閾値を見直し、見逃しがある場合は監視項目を追加します。高可用性Web開発では、監視を一度設定して終わりにせず、運用しながら育てることが大切です。

16.2 定期的に負荷テストする

負荷テストは、システムがどの程度のアクセスに耐えられるかを確認するために重要です。通常時の運用だけでは、ピーク時や障害時の挙動が分かりません。負荷テストを行うことで、CPU、メモリ、DB、キャッシュ、ネットワーク、外部APIのボトルネックを見つけられます。

負荷テストは、機能追加やキャンペーン前にも有効です。新機能が既存システムにどの程度負荷を与えるのかを事前に確認できます。高可用性Web開発では、想定アクセスに対して本当に耐えられるかを定期的に検証することが重要です。

16.3 障害訓練を実施する

障害訓練は、運用チームが障害時に適切に動けるかを確認するために重要です。サーバー停止、DB障害、外部API停止、ネットワーク障害、デプロイ失敗などを想定し、検知、連絡、復旧、報告までの流れを確認します。訓練をしていないと、本番障害時に対応が遅れる可能性があります。

障害訓練では、技術的な復旧だけでなく、コミュニケーションも確認します。誰が判断するのか、どのチャンネルで連絡するのか、ユーザー告知をいつ出すのかを整理します。高可用性は、システムだけでなくチームの対応力によっても支えられます。

17. 高可用性アーキテクチャ設計

高可用性アーキテクチャ設計では、システム全体を分散構成として考えます。アプリケーション、DB、キャッシュ、CDN、Queue、ストレージ、監視、ログ、認証をそれぞれ適切に分離し、一部障害が全体停止につながらないようにします。

クラウドネイティブな設計では、マネージドサービス、マルチAZ、オートスケール、ロードバランサー、IaC、コンテナ、サーバーレスなどを活用できます。ただし、クラウドを使うだけで高可用性になるわけではありません。サービスごとの責任範囲と障害パターンを理解することが重要です。

17.1 分散構成を基本にする

高可用性アーキテクチャでは、分散構成を基本にします。単一サーバーにアプリケーション、DB、ファイル保存、バッチ処理をすべて載せる構成は、シンプルですが障害に弱くなります。役割ごとに構成要素を分け、必要に応じて冗長化することで、障害影響を限定できます。

分散構成では、サービス間通信、ログ統合、監視、デプロイ、認証、データ整合性が複雑になります。分散すればよいわけではなく、運用できる範囲で分散することが重要です。高可用性Web開発では、シンプルさと耐障害性のバランスを取る必要があります。

17.2 クラウドネイティブ設計にする

クラウドネイティブ設計では、クラウドの特性を活かして可用性を高めます。ロードバランサー、オートスケーリング、マネージドDB、オブジェクトストレージ、Queue、CDN、監視サービスなどを活用すれば、自前運用よりも高可用性を実現しやすくなります。

ただし、マネージドサービスにも障害は起こり得ます。クラウドサービスのSLA、リージョン構成、バックアップ、復旧手順を理解する必要があります。クラウドネイティブ設計では、クラウドに任せる部分と、自社で設計すべき部分を切り分けることが重要です。

17.3 マルチAZ・マルチリージョン対応

マルチAZ構成は、同一リージョン内の複数の可用性ゾーンにシステムを配置する構成です。1つのAZに障害が起きても、別AZでサービスを継続できる可能性があります。多くのWebサービスでは、まずマルチAZ構成を検討することが現実的です。

マルチリージョン対応は、より高度な可用性を目指す構成です。リージョン全体の障害に備えられますが、データ同期、レイテンシ、コスト、運用が複雑になります。高可用性Web開発では、サービスの重要度に応じて、マルチAZで十分なのか、マルチリージョンまで必要なのかを判断することが大切です。

18. パフォーマンスと可用性の関係

パフォーマンスと可用性は密接に関係しています。システムが停止していなくても、レスポンスが極端に遅い場合、ユーザーにとっては利用できない状態に近くなります。高可用性Web開発では、単にサーバーが生きているかではなく、実用的な速度でサービスを提供できているかを見る必要があります。

パフォーマンスが悪化すると、ユーザー離脱だけでなく、障害リスクも高まります。高負荷状態が続くと、DB接続枯渇、Queue滞留、タイムアウト、リトライ増加が発生し、最終的にシステム停止につながることがあります。パフォーマンス最適化は、可用性向上の重要な施策です。

18.1 遅延は障害と同等になる

Webサービスでは、遅延が大きくなると障害と同等の影響を与えることがあります。ページ表示に数十秒かかる、APIがタイムアウトする、決済処理が進まない場合、ユーザーはサービスが止まっていると感じます。可用性を考える際は、稼働しているかだけでなく、応答速度も重要です。

遅延を防ぐには、レスポンスタイム監視、DB最適化、キャッシュ、CDN、非同期処理、API改善が必要です。高可用性Web開発では、ユーザーが許容できる速度をSLOとして定義し、継続的に監視することが効果的です。

18.2 高負荷は停止リスクになる

高負荷状態は、サービス停止の前兆になることがあります。CPUやメモリ使用率が高い、DB接続数が上限に近い、Queueが溜まり続ける、外部APIへのリトライが増えるといった状態は、障害につながる可能性があります。高負荷を放置すると、連鎖的にシステム全体が不安定になります。

高負荷への対策としては、スケールアウト、キャッシュ、レート制限、Queue、処理分離、DBチューニングが有効です。特に、書き込み処理や重い集計処理は非同期化することで、ユーザー向け処理への影響を減らせます。高可用性では、高負荷時にどう劣化させるかも重要な設計です。

18.3 最適化は可用性に直結する

パフォーマンス最適化は、可用性に直結します。不要な処理を減らし、DBクエリを最適化し、静的コンテンツをCDN配信し、キャッシュを活用することで、システム全体の負荷を下げられます。負荷が下がれば、障害発生リスクも下がります。

ただし、最適化は計測に基づいて行うべきです。感覚で最適化すると、効果の低い箇所に時間を使ってしまう可能性があります。高可用性Web開発では、監視データを見ながら、可用性に影響するボトルネックを優先的に改善することが重要です。

19. 高可用性で重要になる考え方

高可用性で重要なのは、障害が起きない完璧なシステムを目指すことではありません。障害は必ず起きる前提で、影響を小さくし、早く検知し、素早く復旧し、再発防止へつなげることです。高可用性は、設計、実装、運用、改善を含む継続的な取り組みです。

また、高可用性にはコストがかかります。すべてを冗長化し、マルチリージョンにし、完全自動復旧を目指すと、コストや複雑性が大きくなります。必要な可用性レベルを見極め、ビジネス要件に合った現実的な設計を行うことが重要です。

19.1 障害は必ず起きる前提で設計する

高可用性の基本は、障害は必ず起きる前提で設計することです。サーバー、DB、ネットワーク、外部API、クラウド、デプロイ、人為ミスなど、障害要因は多くあります。障害が起きないことを期待するのではなく、起きたときにどう継続し、どう復旧するかを考えます。

障害前提の設計では、冗長化、監視、ログ、フェイルオーバー、バックアップ、復旧手順、障害訓練が必要です。高可用性Web開発では、正常系だけでなく異常系を設計の中心に置くことが重要です。

19.2 すべてを冗長化する必要はない

高可用性を目指すからといって、すべてを冗長化する必要はありません。重要度の低い管理機能や一時的なバッチ処理まで高コストな冗長構成にすると、費用と運用負荷が増えすぎます。可用性レベルは、機能ごとの重要度に応じて決めるべきです。

たとえば、決済、ログイン、注文処理は高い可用性が必要ですが、社内向けレポート生成は多少遅れても許容される場合があります。高可用性Web開発では、すべてを同じレベルで守るのではなく、守るべき機能を優先することが大切です。

19.3 コストと可用性のバランス

可用性を高めるほど、一般的にコストも増えます。冗長サーバー、マルチAZ、マルチリージョン、監視、運用体制、障害訓練には費用がかかります。可用性を高めることは重要ですが、ビジネス価値に見合わない過剰投資は避ける必要があります。

コストと可用性のバランスを取るには、SLOやRTO、RPOを定義することが有効です。どれくらいの停止が許容されるのか、どれくらいのデータ損失が許容されるのかを明確にすれば、必要な構成を判断しやすくなります。高可用性は、技術的な理想ではなく、事業に合った現実的な設計が重要です。

19.4 運用込みで設計する

高可用性は、運用込みで設計する必要があります。冗長構成を作っても、監視がなければ障害に気づけません。フェイルオーバー機能があっても、手順を知らなければ復旧できません。ログがなければ、障害原因を調査できません。

運用込みで設計するには、監視、アラート、ログ、復旧手順、担当者、障害訓練、インシデント管理を初期段階から考えます。高可用性Web開発では、開発チームと運用チームが連携し、システムと人の両方で信頼性を支えることが重要です。

19.5 継続改善を前提にする

高可用性は、一度構築すれば終わりではありません。ユーザー数、機能、データ量、クラウド構成、依存サービスは変化します。そのため、監視データ、障害履歴、負荷テスト結果をもとに継続的に改善する必要があります。

継続改善では、障害後の振り返りが重要です。障害を単なる失敗として終わらせず、なぜ起きたのか、どう検知したのか、復旧に何分かかったのか、再発防止には何が必要かを整理します。高可用性Web開発では、障害から学び続ける姿勢が信頼性を高めます。

おわりに

高可用性Web開発戦略は、単なるインフラ構成ではなく、システム設計そのものです。冗長化、負荷分散、フェイルオーバー、データベース高可用性、キャッシュ、CDN、監視、ログ、デプロイ戦略、障害対応、SRE視点を組み合わせることで、止まりにくく復旧しやすいWebサービスを実現できます。高可用性は、ユーザー体験、ビジネス継続、信頼性に直結する重要な考え方です。

一方で、高可用性を高めるほどコストや複雑性も増えます。すべてを最高レベルで冗長化するのではなく、サービスの重要度、ビジネス影響、許容停止時間に応じて、現実的なHA構成を選ぶことが大切です。特にデータベースは最大のボトルネックになりやすいため、レプリケーション、フェイルオーバー、読み取り分離、バックアップ、復旧手順を慎重に設計する必要があります。

Web開発では、クラウドと自動化と信頼性設計がますます重要になります。障害は必ず起きる前提で、監視し、検知し、切り替え、復旧し、改善し続けることが、高可用性Webサービスの基本です。止まらないシステムを作るには、技術構成だけでなく、運用体制と継続改善まで含めて設計することが重要になります。