こんにちは、GMOインターネットグループ株式会社の長谷川です。
今回は ConoHa のインフラ特に公開APIに関してお話して行こうと思います。
ConoHa の API とは
ConoHa VPS は、OpenStack を採用しています。OpenStack 準拠の API を公開しており、コントロールパネルで提供されている機能のほか、VPS の構築やネットワークの設定などのシステム構築に直接関わる部分から、ユーザー情報や請求情報といったアカウント管理などが操作でき、効率良くサーバー管理・運用をすることができます。
https://www.conoha.jp/vps/function/api/
どうやって API インフラを実装していくのか
まず前提として以下の理由から素の OpenStack API をそのまま提供するということはありません。
- 課金データが OpenStack API 単体では管理できないから
- セキュリティーの問題
- 冗長性やパフォーマンスの問題
上記の理由から LVS, HAProxy, API ラッパーを使い冗長構成やセキュリティーの課題に対して対応していきます。
LVS, keepalived, HAProxy とは何ぞや?
LVS
Linux virtual server のことで Linux の負荷分散ソリューションの一つ。
LVSは IPVS (IP virtual server) と ipvsadm ユーティリティから構成されており layer4 の負荷分散を提供する。
keepalived
LVS と一緒に使われ VRRP などの protocol を利用し、LVS サーバを監視して冗長化を行う。
HAProxy
高可用性、負荷分散を提供するプロキシ兼ロードバランサーである。
layer7 の負荷分散を可能にしている。
インフラ構成
![](https://developers.gmo.jp/wp-content/uploads/2023/10/img_01.png)
上記は API を公開する際の基本的な構成の一部になります。
LVS & keepalived により、HAProxy に VIP(Virtual IP)を付与します、これにより片系の HAProxy が落ちたとしても VIP 経由のアクセスは切り替わり継続してサービスの提供を行うことが出来ます。
また、LVSとkeepalived 自体も2台でHAの構成を取ることにより冗長性を高めています。
アクセス時の流れ(リクエスト時)
![](https://developers.gmo.jp/wp-content/uploads/2023/10/img_02.png)
1.APIのエンドポイントにクライアントからアクセスします。
2. クライアントからアクセスを受けるとエンドポイントの FQDNはVIPに名前解決され、リクエストは VIPに流れます。VIPは負荷分散も兼ねているので、VIPに来たリクエストは2台あるうちのどちらかの HAProxy に流れます。
3.HAProxyは設定ファイルに記述されたACLを読み込んでアクセスの許可、どのバックエンドにリクエストを送るのか、それぞれのバックエンドに合わせたパスの書き換え等を行います。
![](https://developers.gmo.jp/wp-content/uploads/2023/10/img_03.png)
4. HAProxyでは複数のバックエンドを後ろに置くことが出来ます。
よって、エンドポイントごとやメソッドごとにリクエストを転送する先のバックエンドを切り替える事が出来ます。(エンドポイントとメソッドによってAPIラッパーに転送したり選ぶことが出来ます。)
アクセス時の流れ(レスポンス時)
![](https://developers.gmo.jp/wp-content/uploads/2023/10/img_04.png)
上記の図のように レスポンスをクライアントに返すときは、バックエンド → HAProxy の経路をたどりその後 Direct Server Return (DSRと呼ばれます)で HAProxy から直接クライアントにレスポンスを返します。
レスポンスを DSR で返す理由は、レスポンスに使われる経路が減ることにより負荷の軽減や処理速度の向上につながるからです。
全体的な構成
実際に運用する際の構成では internal(スタッフアクセス用 API ), external (お客様アクセス用 API )で上記のセットが 2つ必要になります。
また、兼用されるものもあるため internal, external を合わせた構成は以下のようになります。
![](https://developers.gmo.jp/wp-content/uploads/2023/10/img_05.png)
上記の図に関しては、最低限の 1セットの構成を図で示したものとなります。
システムの要件により、この構成のセットが増えていきます。
アクセス数が多い API のエンドポイントやファイルアップロード等の負荷のかかるエンドポイントでは上記のシステム構成を別で持ち、通常系の API と分ける事により負荷の影響が他のエンドポイントに及ばないような設計になっています。
まとめ
ConoHa API のシステムに関して、簡潔に解説しましたがどうでしたでしょうか?
API エンドポイントの負荷対策やセキュリティーは重要なものとなり、今回解説した部分は一部でしかありませんが、解説した仕組みを用いてお客様が使いやすいよう API を提供しています。
是非 ConoHa で API を利用して VPS の操作を自動化してみてはいかがでしょうか?
![](https://developers.gmo.jp/wp-content/uploads/2022/11/bnr_conohaVPS_707x370.png)
ブログの著者欄
採用情報
関連記事
KEYWORD
CATEGORY
-
技術情報(401)
-
イベント(136)
-
カルチャー(34)
TAG
- 5G
- Adam byGMO
- AI
- AWX
- BIT VALLEY
- blockchain
- ChatGPT
- cloudnative
- CloudStack
- CM
- CNDO
- CNDT
- CODEGYM Academy
- ConoHa
- CS
- CSS
- CTF
- DC
- DevSecOpsThon
- Docker
- DTF
- F16
- GitLab
- GMO Developers Day
- GMO Developers Night
- GMO Hacking Night
- GMO kitaQ
- GMO SONIC
- GMOアドパートナーズ
- GMOアドマーケティング
- GMOイエラエ
- GMOグローバルサイン
- GMOデジキッズ
- GMOペイメントゲートウェイ
- GMOペパボ
- GMOリサーチ
- Go
- gohercloud
- GTB
- Hadoop
- Hardning
- Harvester
- HCI
- iOS
- IoT
- ISUCON
- JapanDrone
- Java
- JJUG
- JS
- jumpy
- k3os
- k3s
- K8s
- Kids VALLEY
- kubevirt
- KVM
- Linux
- longhorn
- MetaMask
- Misaki
- MySQL
- NFT
- nginx
- OpenNebula
- OpenStack
- Perl
- PHP
- PHPcon
- PHPerKaigi
- QUIC
- Rancher
- RPA
- Ruby
- Selenium
- splunk
- SRE
- SSL
- TLS
- TypeScript
- UI/UX
- VLAN
- VM
- VS Code
- インターンシップ
- オブジェクト指向
- オンボーディング
- お名前.com
- カルチャー
- コンテナ
- スクラム
- スペシャリスト
- ソフトウェアテスト
- チームビルディング
- ドローン
- ネットワーク
- プログラミング教育
- ブロックチェーン
- ゆめみらいワーク
- リモートワーク
- 基礎
- 多拠点開発
- 宮崎オフィス
- 応用
- 技育プロジェクト
- 新卒
- 暗号
- 機械学習
- 決済
PICKUP