データインフラ用の固定IPアドレス

<font color="Grey">*[Static IP addresses for your data infrastructure](https://aiven.io/blog/static-ip-for-your-service)の翻訳です。*</font>

2023年1月5日

# データインフラに固定IPアドレスを

通常、サービスには動的IPアドレスを使用するのがベストですが、静的IPアドレスが意味を持つ場合もあります。その理由については、こちらをお読みください。

インフラストラクチャの近代化プロジェクトにおいて、ネットワークは重要な役割を果たします。あなたが近代化プロジェクトのコンサルタントで、データは（Aiven）クラウドデータベースに移行されたが、一部のレガシーアプリケーションはまだオンプレミスにあるとします。これらのレガシー・アプリケーションとそのネットワーク・ファイアウォールは、静的なIPアドレスとポートを期待している。この記事では、データ・インフラにおける静的IPアドレスの使用例について説明し、Aivenリソースで静的IPアドレスを使用するためのリソースを紹介します。


## オンプレミスネットワークファイアウォール


近代化プロジェクト用のオンプレミスのエンタープライズ・アプリケーションは、クラウド・データベースからの読み取り/クラウド・データベースへの書き込みを行う必要があるが、セキュリティ・エンジニアリング組織には、許可リストに含まれるいくつかのアドレス/ポートを除き、すべての送受信アドレス/ポートを自動的に拒否するネットワーク・ファイアウォール・ルールがある。システムは以下のようになっている：


![ファイアウォールがインバウンド・アウトバウンドの接続をブロックしている](https://cdn.sanity.io/images/sczeoy4w/production/49df52068ff55cde1e8cbbcb8beed27666d2122e-1083x551.png?q=80&fit=min&auto=format&dpr=1.5)


クラウドデータベースはIPアドレスではなくホスト名で参照されることにお気づきだろうか。これによって、基礎となるIPアドレスが時間の経過とともに変更されたとしても（たとえば、メンテナンス・ウィンドウの間）、クライアントは同じ完全修飾ドメイン名（FQDN）またはサービス名を使用してデータベース・インスタンスと会話することができます。レガシー・アプリケーションのファイアウォール・ルールは、すべての送受信接続の許可リストに追加できるIPアドレスしか受け入れないため、これはセットアップの障害となります。


より一般的なシナリオは、アプリケーションはクラウド上でホストされているが、オンプレミスのデータベースはファイアウォールの背後にあるというものだ。このような状況では、ファイアウォールが送受信接続を許可するように設定できるように、クラウドリソースに静的IPアドレスが必要です。


## サードパーティまたはレガシーアプリケーション


近代化プロジェクトのクライアントから、サードパーティのメトリクス収集サービスとレガシーバックアップアプリケーションをクラウドデータベースに統合するよう依頼されました。サードパーティとレガシーのアプリケーションには共通点があることがわかりました。これらのアプリケーションはどちらも、データベースに接続するときにホスト名ではなくIPアドレスを要求します。


カスタムのDNSリゾルバを追加することもできますが、それはパフォーマンスのオーバーヘッドを追加する可能性があり、単一のポイント・イン・タイムの問題を解決するためだけに、大規模なインフラストラクチャーのイニシアチブを取るには大きすぎるかもしれません。


## 静的IPアドレスの救済


あまり利用されていないが、静的IPアドレスは上記のようなシナリオに対する素晴らしい解決策となる。IPベースのファイアウォールルールでは、クラウドリソースのIPアドレスとポート番号を簡単に許可することができる。


![ファイアウォールはIP/ポートに基づいてリソースを許可する](https://cdn.sanity.io/images/sczeoy4w/production/609391ebbad4bf6ea6c66e2666b36f152e20bc88-1083x551.png?q=80&fit=min&auto=format&dpr=1.5)


これらはネットワーク・ファイアウォールであることに留意してください。

[レイヤー3](https://en.wikipedia.org/wiki/OSI_model#Layer_3:_Network_layer)/[レイヤー4](https://en.wikipedia.org/wiki/OSI_model#Layer_4:_Transport_layer)

ファイアウォールであり、[Web Application Firewalls](https://en.wikipedia.org/wiki/Web_application_firewall) (WAF) ではありません、

[レイヤー7](https://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application_layer)のファイアウォールである[Web Application Firewall](https://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application_layer) (WAF)ではありません。


オンプレミスのアプリケーションがファイアウォールの背後にあり、Aivenサービスと通信する必要がある場合は、コンソール、Aiven CLI、または[Aiven Provider for Terraform](https://registry.terraform.io/providers/aiven/aiven/latest)を使用して、[Aiven上に静的IPアドレスを作成する](https://developer.aiven.io/docs/platform/concepts/static-ips.html)ことができます。高可用性とフェイルオーバーのためには、サービスに十分な数の静的IPアドレスが割り当てられていることを確認したいでしょう。


目安としては、ノード数が6台までならその2倍、6台以上なら「ノード数+6」個の静的IPアドレスが必要です。静的IPアドレスの消費にはコストがかかりますが、これらのIPアドレスをAivenのどのサービスにも割り当てることができます。事前に[静的IPアドレスの計算と予約](https://docs.aiven.io/docs/platform/howto/static-ip-addresses.html)をしておけば、Aivenがこれらの静的IPアドレスをご希望のクラウド上にプロビジョニングしてくれます。


## まとめ


静的IPアドレスの適切な使用とAivenリソースのスムーズな設定のおかげで、インフラ近代化プロジェクトは成功裏に完了しました。静的IPアドレスの使用例と、Aivenサービスのためにどのように[設定](https://developer.aiven.io/docs/platform/concepts/static-ips.html)できるかをご理解いただけたと思います。


また、独自のデータインフラを管理する手間を省きたい方は、ぜひAivenをお試しください(https://console.aiven.io/signup)。