Kinstaは高可用性(HA)ホスティングを提供しませんが、SLAによるアップタイム保証は提供しています。Kinstaのプラットフォーム上の各サイトは単一のLinuxコンテナで実行され、サイトデータベースはサイトコンテナ内のサービスとして実行されます。ロードバランス等の目的で、各サイトの複数インスタンスを実行することはありません。詳細については記事「Kinstaのアーキテクチャ」をご覧ください。

コンテナベースのインフラストラクチャ、エンジニアリングチームによるプロアクティブな負荷管理、クラス最高のクラウドプロバイダーGoogle Cloud Platformの柔軟性により、KinstaはSLAによる99.9%のアップタイム保証を提供します。

アップタイムモニターが妨害されるシナリオ

確実にアップタイム保証を満たすため、Kinstaはプラットフォーム上のすべてのサイトのアップタイムを監視しています。アップタイムモニターで障害が発生した場合、当社のエンジニアが直ちに対応し、サイトのサービス復旧に努めます。しかし、アップタイムモニターの機能が制限されるシナリオがいくつかあります。

  • 基本認証が有効な場合、すべての未承認リクエストに対して401エラーを返します。
  • Cloudflareの「I’m under attack」モードでは、DDoS攻撃を避けるために5秒の待機時間があります。これはHEADリクエストには適用されず、503エラーを返します。
  • リバースプロキシサイトで、プライマリドメインがターゲットURLにリダイレクトしていない場合。
  • WordPress以外のサイト。Kinstaでは監視できません。
  • カスタムキャッシュの特定のインスタンス、例えば、Kinstaのクエリ文字列のHEADリクエストをキャッシュすると、問題が発生する場合があります。SucuriやCloudflareなどのプロキシサービスも、設定によってはキャッシュで同様の問題が発生します。
  • ボットブロックサービス。Kinstaのアップタイムモニターはユーザーエージェントとしてkinsta-botを使用します。プラグインやユーザーエージェント拒否サービスでボットをブロックすると、アップタイムモニターが失敗し、通常は、406レスポンスコードを返します。
  • アップタイムモニタのIPアドレス、または発信国(Geo-block)のいずれかをブロックすると、監視に影響します。Kinstaのサーバーでこの機能を構成する場合は例外が追加されるため、問題になりません。
  • プライマリドメインが、追加されたインストールに解決しないか、または同じサイトのドメインリストに含まれる別のドメインにリダイレクトされている場合。
  • サイトのメンテナンスモード時。503レスポンスを返す場合があります。

時間とコストを節約し、サイトパフォーマンスを最大化します。

  • 24時間年中無休でお問い合わせいただけるWordPressホスティングの専門家からの即座なサポート。
  • Cloudflare Enterpriseとの統合。
  • 世界各地に設置された32カ所のデータセンターでグローバルなオーディエンスに対応。
  • アプリケーションのパフォーマンス監視機能を使った最適化。

長期契約は必要ではありません。サーバー移行のサポート、30日間の返金保証など、さまざまなサービスを提供しております。お客様に最適なプランをご提案いたしますので、お気軽にお問い合わせください。または、当社のプランをご確認ください。