商業登記簿APIの(一部)オンプレ移行

株式会社ティヒでは、これまで商業登記簿API「登記くん」の運用をクラウドリソースのみで行ってきました。クラウドは非常に便利ですが、インスタンスのスペックに対してコストが高く、特に将来のリクエスト数がある程度予測できる場合、一部をオンプレミスに移行することで大きなコスト削減のメリットがあります。

今回は、商業登記簿API「登記くん」においてどのようにオンプレミスを活用し、移行時にどのように構成を変更したかをご紹介します。

商業登記簿API「登記くん」について

本題とは関係ないため簡単に説明します。

本サービスは、契約したお客様が月に100件～1000件の登記簿取得リクエストを行えるAPIです。月間リクエスト数は「お客様の数 × 100～1000件」程度と非常に少ないです。

リクエスト処理では、民事法務局の登記簿提供サービスを呼び出してPDFを取得し、解析した結果をレスポンスに含めます。この際、PDF解析処理に一定のCPUリソースが必要となります。

元々の構成

Vultr LB
   |
   |-- Vultr Instance 1 --|
   |                      |-- Vultr DB
   |-- Vultr Instance 2 --|

DBを選定する際、マネージドサービスで東京リージョンがあり、比較的安価だったVultrを採用しました。そのため、Vultrにロックインされ、Vultr LBにインスタンスを接続する構成を取っていました。

改善後の構成

Nginx LB (さくらインターネット)
   |
   |-- オンプレ　1　　　 --|
   |            　　　   |-- Vultr DB
   |-- オンプレ　2 　　　--|
   |-- Vultr Instance --|

Vultr LBではVultrのインスタンスしか接続できなかったため、さくらインターネットのインスタンス上にNginxをインストールし、ロードバランサー（LB）として利用しました。AWSのALBも検討しましたが、

• スケーラビリティが不要である
• オンプレミスとVPCを接続する手間
• コスト面

を考慮し、採用しませんでした。

オンプレミスサーバーとしてmini PCを活用し、冗長性を確保するために地理的に分散した2台を用意しました。加えて、バックアップとして、旧構成より若干スペックを落としたVultrインスタンスもクラスターに参加させています。

オンプレミスへの移行に初期費用はかかりましたが、ランニングコストはクラウドのインスタンスを借りる場合の約1/10となり、半年程度で投資を回収できました。

（さくらのインスタンスは値段に対して、性能が良くておすすめです。

終わりに

今回の移行はシンプルなものですが、小規模サービスにおけるインフラ構成の公開例は少なく、各種サービスの比較検討には試行錯誤がありました。

サービスの特性によって最適な構成は異なりますが、本記事が何らかの参考になれば幸いです。