CORPORATE

技術情報

ConoHaとTerraformで始めるインフラ自動化 後編：GPUサーバー構築と運用ガイド

本記事ではConoHa VPS Ver.3.0とTerraformを用いたインフラ管理の応用として、NVIDIA L4 GPU搭載GPUサーバーの構築方法を解説します。サンプルコードを使用し、具体的な手順に従って実用的なConoHaとTerraformの組み合わせ方を紹介します。
前編の「導入から基本のサーバー構築まで」もご確認ください。

1. 実践編：TerraformでNVIDIA L4 GPUサーバーを構築

ConoHa VPSでは記事執筆時点で「NVIDIA H100」や「NVIDIA L4」GPUを搭載した仮想サーバーを利用することができ、本セクションでは「NVIDIA L4」GPU搭載のサーバーをTerraformで構築します。価格や仕様などについては以下の公式サービスページを参照してください。

https://www.conoha.jp/vps/gpu/

事前準備

GPU搭載サーバーは通常のサーバーに比べてコストが高いため、ご利用には事前の申込み審査が必要です。こちらのフォームからお申込みいただくと、審査結果がメールで通知されます。 (通常2～3営業日以内) 1

サンプルコードの概要

以下の3つのコードを利用して実現します。

  • ブートボリュームの作成 (examples/create_boot_volume)
  • 追加ボリュームの作成 (examples/create_additional_volume)
  • NVIDIA L4 GPUサーバーのプロビジョニング (examples/create_gpu_server_with_existing_volumes)

追加ボリュームを利用したサンプルになっている理由は、ブートボリュームは100GB固定サイズのため、GPUサーバーの利用シーンを想定すると容量が逼迫する可能性があるためです。追加ボリュームの価格や仕様などについてはこちらを参照してください。

また前セクションとは異なり、ブートボリュームと追加ボリュームの作成を別のコードで行う理由は、GPUサーバーを削除した場合でもボリュームのみを残したままにすることでデータを保持するためです。

ただし、ブートボリュームは無料で利用できる都合上、サーバーにアタッチしていないブートボリュームの数には制限があります。制限に達してエラーになった場合は不要なブートボリュームを削除するか、イメージ保存機能を利用してボリュームの中身をイメージ化した後に削除して、新たにブートボリュームを作成してください。

なお、本記事ではGPUサーバーの初期起動までの手順を解説しています。NVIDIA GPU搭載サーバー特有の設定や機械学習・AI関連の実用例等に関しては扱っていませんのでご留意ください。

ステップ1: ブートボリュームの作成

まずはブートボリュームを作成します。

ファイル: examples/create_boot_volume/main.tf

実行方法

examples/create_boot_volume ディレクトリに移動します。もしリポジトリのクローンや認証情報の準備が済んでいない場合は前編の「環境構築：スムーズな開始のために」を実施してから続行します。

cd examples/create_boot_volume

ConoHaの認証情報と作成に必要な変数を環境変数として設定、またはterraform.tfvarsファイルに記述します。

以下はterraform.tfvarsファイルの記述例です。(main.tfと同じディレクトリに配置します)

conoha_v3_auth_url        = "https://identity.c3j1.conoha.io/v3"
conoha_v3_tenant_name     = "gnct********"
conoha_v3_user_name       = "gncu********"
conoha_v3_password        = "****************"

boot_volume_name          = "your-terraform-boot-volume-name"

terraform init を実行して必要なプロバイダーをダウンロードします。

terraform init

terraform plan を実行して作成されるリソースを確認します。

terraform plan

terraform apply を実行してブートボリュームを作成します。

terraform apply

成功すると以下のような出力が表示されます：

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

boot_volume_id = "4c816a36-2e2e-4894-9819-29d00fbc627a"
boot_volume_name = "your-terraform-boot-volume-name"

コードの説明

main.tf内の以下の箇所では、variables.tfに記載しているimage_name から、対象のイメージIDを取得します。(サンプルコードではvmi-ubuntu-22.04-amd64を指定)

...
# イメージID取得
data "openstack_images_image_v2" "image" {
  name        = var.image_name
  most_recent = true
}
...

もし利用するイメージを変更したい場合はterraform.tfvarsにてimage_nameを指定(上書き)します。

...
image_name = "vmi-nvidia_docker-latest-ubuntu-22.04-amd64"

以下では取得したイメージIDを用いて、100GBのブートボリュームを作成しています。

...
# ブートボリューム作成
resource "openstack_blockstorage_volume_v3" "boot_volume" {
  name = var.boot_volume_name
  size = 100 # 1GBプラン以上は100GB, 512MBプランは30GB固定
  image_id = data.openstack_images_image_v2.image.id
  volume_type = var.boot_volume_type_name
}
...

outputs.tfでは作成されたボリュームの名前とIDを出力しています。

output "boot_volume_id" {
  description = "The ID of the boot volume."
  value = openstack_blockstorage_volume_v3.boot_volume.id
}

output "boot_volume_name" {
  description = "The name of the boot volume."
  value = openstack_blockstorage_volume_v3.boot_volume.name
}

ステップ2: 追加ボリュームの作成

ファイル: examples/create_additional_volume/main.tf

実行方法

examples/create_additional_volumeディレクトリに移動します。

cd examples/create_additional_volume

ステップ1と同様にConoHa の認証情報と作成に必要な変数を設定します。これは環境変数として設定するか、terraform.tfvars ファイルに記述します。

以下は terraform.tfvars ファイルの記述例です (main.tfと同じディレクトリに配置します) : 

conoha_v3_auth_url        = "https://identity.c3j1.conoha.io/v3"
conoha_v3_tenant_name     = "gnct********"
conoha_v3_user_name       = "gncu********"
conoha_v3_password        = "****************"

additional_volume_name    = "your-terraform-additional-volume-name"

ステップ1と同様にプロバイダーをダウンロードし、実行計画を確認した後、リソースを作成します。

terraform init
terraform plan
terraform apply

成功すると以下のような出力が表示されます：

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

additional_volume_id = "329b78d1-0960-48a5-9fe6-1a5267bc49e1"
additional_volume_name = "your-terraform-additional-volume-name"

コードの説明

main.tf内の以下のコードは、保存イメージから追加ボリュームを作成する場合に利用します。今回は空のボリュームを作成するため、コメントアウトしています。

...
# イメージID取得
# data "openstack_images_image_v2" "image" {
#   name        = var.private_image_name
#   most_recent = true
# }
...

以下のコードで追加ボリュームを作成しています。サイズは200GBから10TBまで選択できますが、今回は200GBとします。

...
# 追加用ボリューム(追加ディスク)作成
resource "openstack_blockstorage_volume_v3" "additional_volume" {
  name = var.additional_volume_name
  size = 200 # 200, 500, 1000, 5000, 10000 から選択
  # image_id = data.openstack_images_image_v2.image.id # 保存イメージからボリュームを作成する場合に指定
  volume_type = var.additional_volume_type_name
}
...

ステップ3: NVIDIA L4 GPUサーバーのプロビジョニング

ファイル: examples/create_gpu_server_with_existing_volumes/main.tf

実行方法

examples/create_gpu_server_with_existing_volumes ディレクトリに移動します。

cd examples/create_gpu_server_with_existing_volumes

ステップ1と同様にConoHaの認証情報と作成に必要な変数を環境変数として設定、またはterraform.tfvarsファイルに記述します。

以下はterraform.tfvarsファイルの記述例です。SSH用ポートを開放するセキュリティグループ (IPv4v6-SSH) を指定しており、サーバ作成後に鍵認証ですぐにSSHログインが可能です。

conoha_v3_auth_url        = "https://identity.c3j1.conoha.io/v3"
conoha_v3_tenant_name     = "gnct********"
conoha_v3_user_name       = "gncu********"
conoha_v3_password        = "****************"

boot_volume_name          = "your-terraform-boot-volume-name"
additional_volume_name    = "your-terraform-additional-volume-name"
ssh_keypair_name          = "your-terraform-keypair-name"
ssh_keypair_public_key    = "ssh-rsa AAAAB3NzaC1yc2EAAAA..."
instance_name             = "your-terraform-instance-name"
default_security_group    = "IPv4v6-SSH"
instance_root_password    = "****************"

ステップ1と同様にapplyまで実行します。

terraform init
terraform plan
terraform apply

成功すると以下のような出力が表示されます：

...
  Enter a value: yes

openstack_compute_keypair_v2.keypair: Creating...
openstack_compute_keypair_v2.keypair: Creation complete after 3s [id=terraform-keypair-for-gpu-server]
openstack_compute_instance_v2.gpu_server_01: Creating...
openstack_compute_instance_v2.gpu_server_01: Still creating... [10s elapsed]
openstack_compute_instance_v2.gpu_server_01: Still creating... [20s elapsed]
openstack_compute_instance_v2.gpu_server_01: Still creating... [30s elapsed]
openstack_compute_instance_v2.gpu_server_01: Still creating... [40s elapsed]
openstack_compute_instance_v2.gpu_server_01: Still creating... [50s elapsed]
openstack_compute_instance_v2.gpu_server_01: Creation complete after 52s [id=fd7a18ce-acfe-4569-b228-e2878062ef5d]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

gpu_server_01_access_ip_v4 = "xxx.xxx.xxx.xxx"
gpu_server_01_id = "dc2247df-d3d3-492f-b7fa-1ec30875cce1"

これでGPU搭載サーバーの作成が成功しました。

サーバに設定されたIPアドレスの情報 (gpu_server_01_access_ip_v4) を元に、指定した鍵でSSHができるところまで確認します。

$ ssh [email protected] -i ~/.ssh/your_key_name
The authenticity of host 'xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)' can't be established.
ED25519 key fingerprint is SHA256:your_fingerprint_here.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xxx.xxx.xxx.xxx' (ED25519) to the list of known hosts.
Enter passphrase for key '~/.ssh/your_key_name': 
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-79-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Wed Aug 14 03:29:31 PM JST 2024

  System load:           0.15283203125
  Usage of /:            6.0% of 98.25GB
  Memory usage:          0%
  Swap usage:            0%
  Processes:             283
  Users logged in:       0
  IPv4 address for eth0: xxx.xxx.xxx.xxx
  IPv6 address for eth0: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


The list of available updates is more than a week old.
To check for new updates run: sudo apt update

root@vm-1f0ff05c-2e:~#

無事SSHでログインができました。

コードの説明

作成するサーバのフレーバーの定義をvariables.tfにて行っています。NVIDIA L4 GPUが1枚利用可能なフレーバーをデフォルト値として設定しています。

...
variable "flavor_name" {
  description = "The name of the flavor to be used for the instance."
  default     = "g2l-t-c20m128g1-l4" # 20vCPU, 128GB RAM, 100GB Disk, NVIDIA L4 GPU
}
...

もし他のフレーバーを利用したい時、例えばNVIDIA H100 GPUが一枚利用可能なフレーバーを利用する際は以下のようにterraform.tfvarsでflavor_nameを上書きします。

...
boot_volume_name          = "your-terraform-boot-volume-name"
additional_volume_name    = "your-terraform-additional-volume-name"
...
...
flavor_name = "g2l-t-c22m228g1-h100" # NVIDIA H100 GPU を指定

またmain.tfの以下の箇所では、前編でのサンプルコードとは異なりボリュームを作成する記述がない代わりに、作成済みのボリュームの情報を取得するコードとなっています。

...
# 既存のブートボリュームを取得
data "openstack_blockstorage_volume_v3" "existing_boot_volume" {
  name = var.boot_volume_name
}

# 既存の追加ボリュームを取得
data "openstack_blockstorage_volume_v3" "existing_additional_volume" {
  name = var.additional_volume_name
}
...
ボリューム利用に関する注意点と補足について

ConoHaでは同一名で複数のボリュームを作成できますが terraform-provider-openstack プロバイダーでは名前で一意に特定するため、同一名のボリュームが複数ある場合はエラーになります。
そのためボリューム名でのリソース管理よりもボリュームのユニークなID (UUID) での管理が適切な状況の場合は、ボリュームのIDをvariablesとして管理し、利用する方法も有効です。

次に以下の箇所では、追加ボリュームを自動的に初期化しマウントするuser-dataスクリプトを呼び出しています。(var.mount_point変数はvariables.tfファイルにてデフォルトで/mntを指定しています)

...
# ユーザーデータ取得
data "template_file" "user_data" {
  template = file("${path.module}/../../files/user_data/attach_additional_volume.tpl")
  vars = {
    mount_point = var.mount_point
  }
}
...

user-dataスクリプトの中身は以下のように数行の記述となっており、サーバーが起動する際に追加ボリュームが自動的に初期化され、指定されたマウントポイントにマウントされるようになります。

#cloud-config
merge_how:
  - name: list
    settings: [append]
  - name: dict
    settings: [no_replace, recurse_list]
mounts:
  - ["/dev/vdb", "${mount_point}", "ext4", "defaults", 0, 0]
runcmd:
  - mkfs.ext4 /dev/vdb

注意点として、追加ボリュームを一度サーバーから切り離し、別の新規サーバーへアタッチして再利用するシチュエーションなど初期化が行われると困る場合は以下のようにmkfsコマンドは削除し、マウントのみのコードにすることをおすすめします。

#cloud-config
merge_how:
  - name: list
    settings: [append]
  - name: dict
    settings: [no_replace, recurse_list]
mounts:
  - ["/dev/vdb", "${mount_point}", "ext4", "defaults", 0, 0]

ステップ3: クリーンアップ

最後のステップとして、構築したリソースを削除する際の手順を記載します。サーバーを削除してからボリュームを削除するという順で行う必要があります。

1. GPUサーバーを削除したい時：

cd examples/create_gpu_server_with_existing_volumes
terraform destroy

2. GPUサーバーを削除後、ブートボリュームを削除したい時：

※ サーバーを削除する前にブートボリュームの削除を行うことはできません

cd examples/create_boot_volume
terraform destroy

3. GPUサーバーを削除後、追加ボリュームを削除したい時：

cd examples/create_additional_volume
terraform destroy

2. 実運用時に押さえるべきポイント

本記事ではサンプルコードに基づいてConoHaとTerraformの組み合わせ方解説しましたが、実際の運用では以下の点にも注意を払う必要があります。

最適なディレクトリ構成の選択と改善

公式が提供するStyle Guideに従うことは良い出発点です。主に以下のポイントがあります。

  • 環境ごとの設定を分離する (production, developmentなど)
  • リソースタイプ毎に分割する (compute, storage, networkなど)
  • 共通のモジュールを再利用する (モジュール機能の活用)

上記を考慮した一例です：

├── modules
│   ├── compute
│   │   └── main.tf
│   ├── database
│   │   └── main.tf
│   └── network
│       └── main.tf
├── dev
│   ├── backend.tf
│   ├── main.tf
│   └── variables.tf
└── prod
    ├── backend.tf
    ├── main.tf
    └── variables.tf

しかし、実際の環境ではプロダクトライフサイクルのフェーズの変化、インフラの規模、組織の構造、運用の分担などに応じて柔軟に対応する必要があります。重要なのは、一度決めたディレクトリ構成に固執せず、柔軟に見直し、改善していく点であると言えます。

モジュール化による再利用可能なインフラコンポーネントの作成

モジュール化は、Terraformコードの再利用性と保守性を大幅に向上させる強力な手法です。ConoHaでよく使用されるコンポーネントをモジュール化することで、一貫性のあるインフラを効率的に展開できます。

以下は、セキュリティグループ作成をモジュール化した例です：

terraform {
  required_providers {
    openstack = {
      source = "terraform-provider-openstack/openstack"
      version = "~> 2.0.0"
    }
  }
}

# セキュリティグループ作成
resource "openstack_networking_secgroup_v2" "secgroup" {
  name        = var.secgroup_name
  description = var.secgroup_description
}

# セキュリティグループルール作成
resource "openstack_networking_secgroup_rule_v2" "secgroup_rule" {
  count            = length(var.rules)
  direction        = var.rules[count.index].direction
  ethertype        = var.rules[count.index].ethertype
  protocol         = var.rules[count.index].protocol
  port_range_min   = var.rules[count.index].port_range_min
  port_range_max   = var.rules[count.index].port_range_max
  security_group_id = openstack_networking_secgroup_v2.secgroup.id
}

このモジュールを利用する例です：

# セキュリティグループのモジュール
# tcp 80番ポートのingressを許可するセキュリティグループを作成する例
module "secgroup" {
  source = "../../modules/security_group"
  secgroup_name        = "test-secgroup"
  secgroup_description = "Test security group"
  rules = [
    {
      direction      = "ingress"
      ethertype      = "IPv4"
      protocol       = "tcp"
      port_range_min = 80
      port_range_max = 80
    }
  ]
}

セキュリティグループの作成にはセキュリティグループ本体と、そのセキュリティグループに設定する複数のルールの作成/紐づけが必要ですが、モジュール化することでモジュールを利用するコードがシンプルになります。

また上記はセキュリティグループのモジュール化の例でしたが、ローカルネットワークやロードバランサーの構築など、より複雑で順を追った構築手順が必要なリソースでは、モジュール化して再利用可能なコンポーネントとして管理するメリットが一層大きいと言えます。

モジュール化に関するベストプラクティスやより詳細な使用方法について知りたい場合は、Terraformの公式ドキュメントも参照してください。

ステートファイルの重要性と効果的な管理手法

Terraformは現在のインフラ状態をステートファイル (terraform.tfstate) に保存します。このファイルはリソースの現在の状態を記録しており、リソースの追跡、差分の検出、大規模なインフラの管理を効率化するために重要となります。

ステートファイルの管理には以下のポイントがあります。

  • Backend Configuration: デフォルトではローカルディスクに保存されますが、オブジェクトストレージやTerraform Cloudなどのリモートに保存する方法があります。
  • State Locking: Terraformには同時編集による競合を防ぐためにステートをロックする機能があります。ロック機能がサポートされていないバックエンドを利用する場合は、DynamoDBやConsulなどの外部のロックプロバイダの使用を検討します。
  • Protecting sensitive data: ステートファイルには機密情報が含まれるため、用途によっては難読化や適切な保存先を選択する必要があります。

その他の考慮ポイント

実運用時はその他にも以下のような観点も重要です。

  • コスト最適化: インフラの運用コストを最小化するためには適切なスペックの選択、不要なリソースの定期的なクリーンアップや、リソース使用状況の監視が必要です。
  • パフォーマンスチューニング: 大規模なインフラのプロビジョニングにおいては、terraform applyコマンド実行時にparallelismオプションで並列実行数を指定し、高速化することを検討してください。
  • 耐障害性の向上: Terraformを利用してマルチクラウド、マルチAZ (アベイラビリティゾーン) にリソースを配置することで、障害時の影響を最小限に抑えることが可能です。

3. まとめ

本記事では、前編で紹介したConoHa VPS Ver.3.0とTerraformの基本的な組み合わせ方を踏まえ、より実践的なシナリオとしてNVIDIA L4 GPU搭載サーバーの構築と実運用時のポイントについて解説しました。

サンプルコードを中心に、ブートボリュームの作成、追加ボリュームの作成、GPUサーバーのプロビジョニングなど、具体的な手順を示しながら、Terraformを使用したインフラ構築の実際を詳しく説明しています。また、最適なディレクトリ構成、モジュール化、ステートファイルの管理など、運用時に押さえるべきポイントも提示しました。

本記事がConoHaとTerraformを活用したインフラ自動化の第一歩となり、読者の皆様のクラウド環境構築スキル向上と効率的な運用に貢献できることを願っています。

付録

A. トラブルシューティング

1. まずはログレベルの変更

terraformコマンド実行時にエラーが発生した場合、エラーの原因を特定するために環境変数TF_LOGを設定し、デバッグログが出力されるようにします。

export TF_LOG=DEBUG

その後エラーになったコマンドを再実行し、エラー内容を確認します。

2. 認証関連のエラー (“The request you have made requires authentication.”)

terraform.tfvarsや環境変数に設定したAPI認証情報が正しいかを確認してください。

3. リソース作成エラー (“This operation cannot be performed. Number of flavors (plans) allowed per project is limit.)

対象リソースの作成上限数に達しています。上限の緩和申請フォームから申請する必要があります。

4. 405 Method Not Allowed 関連のエラー

ConoHaで未提供のAPIがTerraform経由で実行された場合に発生します。applyコマンドを再実行する際に発生する場合があります。その場合は状況に応じてdestoyコマンドでクリーンアップ後に改めてapplyコマンドを実行してください。

5. 400 Bad Request エラー

400 Bad Request のエラーが発生した場合は様々な要因があります。以下の点を確認してください。

  • すべての必須変数が正しく設定されているか (認証情報、SSHキー、rootパスワード、リソース名など)
  • SSHの公開鍵のフォーマットが正しいか
  • ルートパスワードが十分に複雑で、ConoHaの要件を満たしているか
  • ConoHaで許可されていないパラメータを指定していないか

解決困難であったり、ConoHaのAPIの改善が必要な問題の場合はConoHaのサポート窓口へ問い合わせてください。

B. OpenStack CLIの活用シナリオとセットアップ方法

OpenStack CLIはConoHaのようにOpenStackを基盤とし、OpenStackに準拠したAPIを提供しているクラウドサービスの操作や管理をコマンドラインから行うための強力なツールです。主にTerraformのコードを記述する過程や、トラブルシューティング時の利用が想定されます。

活用シナリオ

  • Terraformで管理していないリソースの確認や操作 (フレーバーやイメージ一覧取得、保有している全てのサーバー情報取得など)
  • トラブルシューティング時の詳細情報取得
  • スクリプトによる自動化タスクの実行

OpenStack CLIのインストール

以下はMacOSにOpenStack CLIをインストールする際のコマンド例です。

pip install python-openstackclient

OpenStack CLIのインストールについての詳細な手順は、公式ドキュメントを参照してください。

認証情報の設定

ConoHaへのアクセスに必要な認証情報を設定します。

環境変数を使用するか、OpenStackクライアント環境スクリプトを作成して読み込む方法があります。以下は、OpenStackクライアント環境スクリプトを作成して読み込む方法の例です。

必要な認証情報を含む PROJECT-openrc.shファイルを作成します。

ユーザ固有の値についてはConoHaのコントロールパネルにログイン後「API」から取得してください。

#!/bin/bash
# This file should be sourced to set up OpenStack CLI environment variables

export OS_AUTH_URL=https://identity.c3j1.conoha.io/v3
export OS_USER_DOMAIN_NAME=gnc
export OS_PROJECT_DOMAIN_ID=gnc
export OS_PROJECT_ID="your_project_id"
export OS_PROJECT_NAME="your_project_name"
export OS_USERNAME="your_username"
export OS_PASSWORD="your_password"
export OS_REGION_NAME=c3j1
export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3

sourceコマンドを使用して、環境変数を設定します。

source PROJECT-openrc.sh

環境変数を設定した後、設定が正しいかを確認します。

openstack token issue

認証トークンが問題なく発行されれば、OpenStack CLI利用の準備が整いました。

OpenStack CLI使用例 (openstack flavor listコマンド)

以下は、openstack flavor listコマンドを用いて「Linux用の時間課金のフレーバー」を取得する例です。主に作成したいサーバーのフレーバー(スペック)を選択する際に利用できます。

output=$(openstack flavor list); echo "$output" | head -n 3; echo "$output" | grep 'g2l-t-'
+--------------------------------------+----------------------+--------+------+-----------+-------+-----------+
| ID                                   | Name                 |    RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+----------------------+--------+------+-----------+-------+-----------+
| 3f8244e7-c7a2-4c60-84b9-cd76dd98a177 | g2l-t-c1m512         |    512 |    0 |         0 |     1 | True      |
| 66394e53-3e1c-455a-a09e-e575520edcef | g2l-t-c22m228g1-h100 | 233472 |    0 |         0 |    22 | True      |
| 6f3c4747-8471-4a38-902b-4c57ad76d776 | g2l-t-c4m4           |   4096 |    0 |         0 |     4 | True      |
| 719b3191-3163-478a-b14c-cb667e0e19b2 | g2l-t-c8m16          |  16384 |    0 |         0 |     8 | True      |
| 784f1ae8-0bc8-4d06-a06b-2afaa9580e0a | g2l-t-c3m2           |   2048 |    0 |         0 |     3 | True      |
| 95afc016-cf7f-4cc1-8622-8790bdc95bb7 | g2l-t-c24m64         |  65536 |    0 |         0 |    24 | True      |
| b5d0e377-3440-41c2-a967-15bbde929325 | g2l-t-c20m128g1-l4   | 131072 |    0 |         0 |    20 | True      |
| b9eb8f9f-6cbf-4c8b-89cd-b0cfb484f13a | g2l-t-c12m32         |  32768 |    0 |         0 |    12 | True      |
| c8ce932a-a7de-4fbb-ab64-903826082be3 | g2l-t-c6m8           |   8192 |    0 |         0 |     6 | True      |
| edb9d02a-a2a6-4b5a-b53b-679259ad73d7 | g2l-t-c88m912g4-h100 | 933888 |    0 |         0 |    88 | True      |
| f2a77529-1815-43a2-bc14-1f3f6b09079c | g2l-t-c2m1           |   1024 |    0 |         0 |     2 | True      |

ConoHa VPS Ver.3.0で提供されているLinux用の時間課金のフレーバー情報が出力されました。

なお、「Windows用の時間課金のフレーバー」は以下のコマンドで取得できます。

output=$(openstack flavor list); echo "$output" | head -n 3; echo "$output" | grep 'g2w-t-'

C. ConoHa GPUサーバーの活用例

ConoHaのGPU搭載サーバーは推論やモデル開発など社内外で様々な用途に活用されていますが、本記事で紹介したTerraformのサンプルコードと親和性の高い活用例を1つご紹介します。

ConoHa VPS の NVIDIA L4 サーバーで Splunk App for Data Science and Deep Learning を使ってみる

上記の記事ではConoHaのNVIDIA L4サーバーで、Splunk App for Data Science and Deep Learning (DSDL)を簡単にセットアップし、GPUを利用したデータサイエンスとディープラーニングの環境を構築する手順を紹介しています。

この環境を活用することで、Pythonコードや複雑なSPLを記述することなく、Transformersライブラリなどを活用したテキストの分類や要約を行い、ビジネス課題を解決するための高度なデータサイエンスとディープラーニングのモデルを簡単に開発できます。

ぜひConoHaのGPU搭載サーバーを活用して、高度なデータ分析や機械学習の可能性を探ってみてください。本記事で紹介したTerraformを活用すれば、このような環境を迅速かつ再現性高く構築できるでしょう。

D. ConoHa用語集

最後に、本記事内やConoHa VPSとTerraformを組み合わせる際に登場する用語を解説します。

1. サーバー / インスタンス / 仮想マシン

本記事内では同義として扱っています。Terraform上で用いられるインスタンス (instance) はConoHa VPSのコントロールパネル上の「サーバー」に相当します。またConoHa VPSのサーバーは記事執筆時点では仮想マシンのみを提供しており、「サーバー」は仮想マシンを指します。

2. フレーバー

AWSでのインスタンスタイプに相当します。RAM、ディスク、コア数などが定義されています。ConoHa VPSでは自身でフレーバーを作成することはできず、提供されているフレーバーの中から適切なものを選択する形式を取ります。

3. テナント / プロジェクト

ConoHaやOpenStackではこの2つの用語が混在していますが、同義です。ConoHa VPSでは利用バージョンやリージョンによってテナントID (プロジェクトID) が異なることがあります。必要に応じてコントロールパネルのAPIメニューからご確認ください。

4. セキュリティグループ

サーバーのネットワーク通信制御を行うホワイトリスト方式のファイアウォール機能で、サーバーに必ず設定する必要があります。サーバー内で適切な設定を行ったにも関わらず通信ができない場合、セキュリティグループの設定を確認してください。

5. ディスク / ボリューム

ディスクはサーバーにおけるブロックデバイス全般を指し、ボリュームはそのブロックデバイスの1つを具体的に表現したものです。ボリュームはデータの保存やアクセスに利用され、サーバー (仮想マシン) にアタッチされることで、サーバーがストレージとして認識し利用可能になります。

  1. 事前の審査が完了がしていない状態でサンプルコードを実行した場合、NVIDIA L4 GPUサーバーのプロビジョニング時にエラーが発生し、正常にサーバーが作成されませんのでご注意ください。 ↩︎

前編

前編の「導入から基本のサーバー構築まで」も併せてご確認ください。

ブログの著者欄

小玉 祥平

GMOインターネットグループ株式会社

2014年よりGMOインターネットグループ株式会社にてバックエンドエンジニアとして従事。OpenStack、Docker、Kubernetesを用いた複数のクラウドサービスのWebAPI設計・開発・運用を10年以上経験。現在は主にConoHaのサービス改善に注力。

採用情報

関連記事

No.1&STEAM人財採用 新卒年収710万プログラム

KEYWORD

CATEGORY

TAG

もっとタグを見る

PICKUP

採用情報

SNS FOLLOW

GMOインターネットグループのSNSをフォローして最新情報をチェック

CATEGORY