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との統合
  • 東京、大阪をはじめとする世界35箇所にあるデータセンターから選択可能
  • アプリケーションのパフォーマンス監視機能を使って最適化を徹底

長期契約による縛りはございません。サーバー移行のサポート、30日間の返金保証など、さまざまなサービスが付帯します。お客様にぴったりのプランをご提案いたしますので、営業までお気軽にお問い合わせください。また、プラン一覧はこちらからご確認いただけます