10Gbps Unmetered Dedicated Servers | DataPacket.com を自社サービスに採用して 1 年以上過ぎたので振り返ってみます。
前提
- 著者は選定と調達を担当しています
- 著者は運用や構築に関して素人であり、実際の運用や構築は行っていません
- オープンになっていない価格については一切書きません
- 自社製品は Raft ベースのクラスター機能を持っています
まとめ (2024-03-03 版)
- DataPacket の利用で不満は今のところない
- マシンとネットワークのコストパフォーマンスが大変良い
- プライベートネットワークに固定できないため DataPacket 間の通信は Tailscale の利用をやめた
まとめ
- DataPacket の利用で不満は今のところない
- マシンとネットワークのコストパフォーマンスが大変良い
- Tailscale との組み合わせが大変良い
なぜ DataPacket を採用したのか
自社製品はリアルタイムな音声と映像、データをサーバー経由でやりとりするパッケージ製品であり、それのクラウド版を提供するにあたり、転送量課金というありきたりの顧客負担が大きいサービスを提供するのではなく、帯域課金という決められた範囲であればつなぎっぱなしで使えるサービスを提供したいと考えていました。
そこで目を付けたのが Discord が採用している DataPacket です。Discord はご存じの通り無料で利用できる音声や映像が活用できるチャットサービスです。Discord は P2P ではなくサーバー経由での音声や映像のやりとりを行っています。つまり膨大な転送量が発生していることになります。
DataPacket は帯域を事前に確保するサービスのため、Discord にとってはおそらく適任だったのでしょう。Discord が DataPacket を利用していることを知ってからは、いつか自社でサービスを提供するときは DataPacket を採用しようと決めていました。
DataPacket お試しプラン
DataPacket にはお試しプランが用意されています。
Request trial | DataPacket.com
自分が試したときは確か $99 で 7 日間お試しができた記憶がありますが、
今はその辺りは記載されていないので、詳細は DataPacket に問い合わせるのが良いと思います。
DataPacket の導入
ハードウェア
DataPacket を導入するにあたって、検討したのがサーバースペックです。
自社製品は Erlang VM ベースであり、コア数が多ければ多いほどスケールします。
そのため、コア数を優先に採用を検討し、AMD EPYC を選定しました。
1 × AMD EPYC 7443P
24 Cores, 48 Threads, 2.85 GHz
メモリや HDD については割愛します。
リージョンはもちろん日本 (東京) です。実際には成田ですが。
ネットワーク
台数を決めた後はネットワーク帯域です。
実は DataPacket は 1 サーバーあたりで帯域の利用を設定するのがデフォルトなのですが、ある程度の台数を契約することで Bandwidth Pooling という機能を利用することができます。
これは一つの帯域をプールとして扱い、複数のサーバーで利用できるようにする仕組みです。
つまりサーバー単位ではなくリージョン単位での帯域を契約することができます。
自社ではこの Bandwidth Pooling を契約して相当な帯域利用にも耐えられるようにしています。
IPv6 アドレスは言えばもらえます。
その他
OS は Ubuntu 22.04 を採用しています。一度ハードを切り替えたタイミングで Ubuntu 20.04 から変更しました。
NIC は 20 GBps x 2 です。
やりとり
DataPacket はイギリスの会社なので、すべてのやりとりは英語になります。また、チケット的な仕組みは一切無く、すべてメールでやりとりします。
ただ 24/365 の対応なので、日本時間の昼間でも普通にメールの返信は反ってきますし、英語は自分のような英語弱者でもとても読みやすく書いてくれます。
Tailscale
DataPacket とそのほかのサーバーとのやりとりは基本的に P2P VPN である Tailscale を利用して通信を行っています。
DataPacket は調達時間が最短でも 4 時間、最長であれば 2 週間かかります。
そのため、もしハードウェア障害があったときに対処できるようにと、自社製品のクラスターネットワークは Tailscale 上に構築しています。
これでハードウェア障害などが発生しても、一時的に Vultr などの短期間でサーバーを用意できるサービスを利用して、暫定対応ができます。
詳細は Tailscale 社のカスタマー紹介をご覧ください。
ベアメタルサーバーを利用したクラウドサービスで発生する課題を Tailscale で解決する · Tailscale
監視
監視には Prometheus ではなく VictoriaMetrics という Prometheus 互換の監視ツールを採用しています。これは TSDB 内蔵でデータ圧縮効果がとても高く、シングルノードで安定して動くというのが強みです。
- VictoriaMetrics · The High Performance Open Source Time Series Database & Monitoring Solution
- VictoriaMetrics: Simple & Reliable Monitoring for Everyone
何かのサービスなどは利用せず自前で VictoriaMetrics を立てています。DataPacket と VictoriaMetrics の通信も Tailscale 経由です。
Grafana
社内向け可視化ツールとしては Grafana を採用しています。
Timescale Documentation | Set up TimescaleDB and Grafana
Grafana との通信も Tailscale 経由です。
ログ収集
ログ収集には Fluent Bit を利用しています。
データのため込み先には TimescaleDB を利用していますが、今後は ClickHouse に変更を検討しています。
価格
価格ですが、大手外資系クラウドサービスや国内クラウドサービスと比較すると転送量を除いておそらく 1/3 程度の価格で用意ができていると思います。
転送量料金はそもそも定額なので、そのまま比較できないのですが、最大まで利用された場合は大手外資系クラウドと比較すると 1/70 程度の価格で利用できていると思います。
実際自社製品を運用するサーバーに DataPacket のベアメタルを採用する事で、サービス自体の価格を大きく抑えられています。
Ubuntu Pro
自社では DataPacket のベアメタルサーバーをできるだけ再起動しないために、Ubuntu Pro を契約して利用しています。
Ubuntu Pro を契約することで Linux カーネルライブパッチ機能が利用でき、再起動回数を減らすことができます。
DDoS Protection
DataPacket の魅力の一つに標準で DDoS プロテクションが付属しています。利用者は何か意識する必要はありません。
Dedicated servers with unmetered DDoS protection | DataPacket.com
雑感
DataPacket は転送量やマシンの性能を重視する場合は選択肢の一つとしてはありだと思います。
ただし、やりとりが英語であること、や本当にベアメタルのサーバーがぽんと渡されるので、IP アドレスの設定ミス一つで、接続できなくなります。その場合は IPMI を利用する必要があります。
管理画面も質素ですし、便利な機能は何一つありません。何もかも自分たちで頑張る必要があります。
ただし、その反面コストを大幅に抑えることができます。このあたりはトレードオフです。
少なくとも自社では DataPacket が無ければ実現したいサービスを提供できなかったと感じています。
もし興味を持ったら使ってみることを検討してみてください。
自社のクラウドサービスの構成は公開してるのでもし良ければどうぞ。
Discussion