おはようございます、サービス基盤部の森田です。

今回は以前から何度かお問い合わせをいただいていたIDCFクラウド RDBへのリージョン/ゾーン間接続例ということで記事を書いてみようと思います。

説明ではプライベートコネクトを使用したリージョン間接続としておりますが、アプリケーションはデータセンターのオンプレ環境で構築し、データベースはバーチャルブリッジを使用してIDCFクラウド RDBに接続して利用したい、と言った構成例でも基本的にRDB側でのルーティング設定を行わずに接続を行うことが出来ます。

今回は、西日本リージョンのaugustaと東日本リージョン3のvoltのネットワークをプライベートコネクトで接続し、augustaに作成したClient用仮想マシンからvoltに作成したRDBへ接続してみます。

事前準備

voltに追加ネットワークを作成

augustaに追加ネットワークを作成

追加ネットワークをプライベートコネクトに接続

仮想ルーターを作成するためにvoltの追加ネットワークを選択してコンピュート上に仮想マシンを作成します(諸々の事情で...)

voltの追加ネットワークを選択してRDBを新規作成

西日本リージョンのaugustaにClient用仮想マシン作成

リージョン/ゾーン間接続用にClient用仮想マシンでスタティックルートを追加

スタティックルートを追加

nmcli c mod "有線接続 1" +ipv4.routes "192.168.0.0/23 192.168.3.254"

設定を有効

nmcli c down "有線接続 1"
nmcli c up "有線接続 1"

ルーティングの設定を確認

[root@rdb-client-01 ~]# ip route
default via 10.21.0.1 dev ens160 proto dhcp metric 101 
10.21.0.0/21 dev ens160 proto kernel scope link src 10.21.0.28 metric 101 
192.168.0.0/23 via 192.168.3.254 dev ens192 proto static metric 102 
192.168.2.0/23 dev ens192 proto kernel scope link src 192.168.2.96 metric 102

voltのRDBへの接続を確認

[root@rdb-client-01 ~]# mysql -utest -p -htest-morita-01.local.rdb.idcfcloud.net
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 136
Server version: 8.0.20 MySQL Community Server - GPL

Copyright (c) 2000, 2021, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> 

まとめ

プライベートコネクトを利用しネットワークを接続したうえで接続元のVMにスタティックルートの設定を入れるだけで、容易にIDCFクラウド RDBへのリージョン/ゾーン間接続を行うことができます。

ただしこの方法では、IDCFクラウド RDBを利用したリージョン/ゾーン間でのRDB側から通信を行うケース(レプリケーション構成においてRDB側がレプリカとなる場合等)に、RDB側のルーティング設定が足りないため、ソースとなるデータベースに接続することができません。この問題については去年リリースしたIDCFクラウド RDBのルーティング機能を使用することで解決することができますので、別の記事にてご紹介いたします。

初めまして、こんにちは。 事業推進本部SE部の掛田（@skakeda）と申します！ 普段はセールスエンジニアとして、自社サービスの説明や導入支援に携わっております。

今回は、Docker環境を利用したコンテナの構築経験はありますが、Kubernetes環境の構築はほぼ未経験の状態である私が、「IDCFクラウド コンテナ」を利用してみた感想について書かせていただきます。
www.idcf.jp

【IDCFクラウド コンテナとは？】

IDCFクラウド コンテナは、オープンソースのコンテナ管理プラットフォーム「Kubernetes」を統合管理することができるマネージドKubernetesサービスです。

サービス概要についてはこちらの記事でまとめておりますのでご覧ください。
blog.idcf.jp

マルチクラウドについて

昨今、クラウド環境の選定にあたり、「マルチクラウド」というワードがトレンドとなっています。

複数ベンダーのクラウドサービスを組み合わせて利用することを意味しており、インフラ基盤をマルチクラウド化することで、システムの柔軟性・可用性を向上させることができます。

マルチクラウド化の課題

既存のマネージドKubernetesサービスの中には、マルチクラウド対応を謳いつつ実際は移設先に縛りがあるなど、ベンダーロックインされてしまうケースが見受けられます。

そういった問題を解決するために、IDCFクラウド コンテナでは「Anyインフラ」を掲げ、オンプレミスからIDCFクラウド環境、GKEなどの他社パブリッククラウド環境にいたるまでクラスタを構築・管理することができます。

そのため、コンテナの利点であるポータビリティを最大限に生かすことのできるサービスとなっています。

「Anyインフラ」のコンセプトについてはこちらの記事をご覧ください！

blog.idcf.jp

【IDCFクラウド コンテナを触ってみた】

前置きが長くなりましたが。。。 それでは、実際にIDCFクラウド コンテナを触ってみた感想についてお話します。

何をしたの？

今回はIDCFクラウド(弊社パブリッククラウド)上にKubernetesクラスタを構築し、Webサーバーのコンテナ(nginx)をデプロイしてみました。作成手順についてはこちらのIDCFクラウド コンテナ めちゃ楽ガイドに沿って進めております。(初めての人に優しいですね)

Kubernetesクラスタを作成してみた

経験談になりますが、自力でKubernetesクラスタを作成しようとすると、コントロールプレーン・ワーカーの環境に、コンテナランタイムをインストールしてから、kubeadmインストールして、、、といった環境を準備する作業に第一のハードルがあると感じます。(私はこの時点でつまずきました。。)

IDCFクラウド コンテナではボタンでポチポチ設定するだけでクラスタの作成をすることができました。ボタン操作のみでクラスタを作成できるのはWEB UIの強みですね。

こちらがクラスタの作成画面になります。 ノードプールのノード数・Role設定を行い、テンプレートを選択し、クラスタ作成をクリックすると作成が始まりました。クラスタを動かすために必要なリソースについても視覚的にわかりやすいのはありがたいです。

クラスタの作成には通常で5分~10分ほどかかります。少し長いと感じますが、ノードの作成・各ツールのインストールからセットアップまでよしなにやってくれるのは助かります。 今回は7分ほどでクラスタの作成ができました。

シークレットの設定

クラスタの作成が完了したので、コンテナをデプロイできる！、、訳ではありません、、 「シークレット」の設定が必要になります。 具体的に、IDCFクラウドのAPIキーをシークレットに登録することで、初めてコンテナをデプロイすることができます。

シークレットとはPodとして実行されるアプリケーションと、その実行時に必要となる秘匿情報(今回はAPIキー)を独立に管理できるリソースことを意味します。

無事、シークレットの設定も完了したところで、早速クラスタにコンテナをデプロイします。

クラスターにコンテナをデプロイしてみた

IDCFクラウド コンテナでは複数のnamespaceを「プロジェクト」という独自の単位で管理します。初期の状態では「Default」と「System」の2つが作成されており、「System」は、Kubernetes環境の設定に必要なプロジェクトになるため、「Default」のプロジェクトを利用するか、新規で作成したプロジェクトを利用します。

今回は、「Default」プロジェクト内にコンテナをデプロイします。 ワークロード画面からデプロイをクリックし、コンテナ名、Dokerイメージ、namespace、ポートマッピングをWEB UIでポチポチ設定します。

コンテナのデプロイもクラスター作成と同様、WEB UIの操作で完結しました！！

私がDockerを利用してWebサーバーのコンテナ(nginx)を立てた際は、仮想ルータでのポートフォワード設定と、nginx側のポート設定をそれぞれ別に行なう必要があったため、WEB UI上でネットワーク設定を一度にできる点が便利だと感じました。

まとめ

以上、IDCFクラウド コンテナ を利用してみた感想についてお話させていただきました。 ある程度の知識は必要であると思いますが、直感的にKubernetes環境を管理できることが本サービスの一番の魅力であると考えております。

また、こちらの記事では紹介できなかった機能(モニタリング設定、Ingressなどなど、)についても、別の記事で紹介させていただきます。

今後ともIDCFクラウド コンテナのさらなる進化にご期待ください！

こんばんは、サービス基盤部の森田です。

前回の記事ではIDCFクラウド RDBへのリージョン/ゾーン間接続例を紹介させていただきましたが、レプリケーション構成において異なるNW間でRDB自身がレプリカとしてソースのデータベースに通信を行うケースについてはRDB側に接続先のスタティックルートの設定が入っていないためRDBからの接続を行うことが出来ません。しかし、去年の12月にRDBでリリースしたスタティックルーティング機能を利用することで今まで実現できなかったRDBからの接続についても可能となりました。 今回はこの機能を使用してリージョン間を跨いだ外部データベース(ソース)/RDB(レプリカ)のレプリケーション構成例についてご紹介してみたいと思います。

事前準備

voltに追加ネットワークを作成

augustaに追加ネットワークを作成

追加ネットワークをプライベートコネクトに接続

仮想ルーターを作成するためにvoltの追加ネットワークを選択してコンピュート上に仮想マシンを作成します(諸々の事情で...)

augustaに外部データベース(ソース)用仮想マシン作成

外部データベース(ソース)側

スタティックルートを追加

nmcli c mod "有線接続 1" +ipv4.routes "192.168.0.0/23 192.168.3.254"

設定を有効

nmcli c down "有線接続 1"
nmcli c up "有線接続 1"

ルーティングの設定を確認

[root@mysql8-source-01 ~]#  ip route
default via 10.21.0.1 dev ens160 proto dhcp metric 100 
10.21.0.0/21 dev ens160 proto kernel scope link src 10.21.0.60 metric 100 
192.168.0.0/23 via 192.168.3.254 dev ens192 proto static metric 101 
192.168.2.0/23 dev ens192 proto kernel scope link src 192.168.2.83 metric 101

MySQLの構築(MySQL8.0を使用)

# Yumリポジトリ追加
dnf localinstall https://dev.mysql.com/get/mysql80-community-release-el8-1.noarch.rpm

# デフォルトのMySQLモジュール無効化
dnf module disable mysql


# MySQLのインストール
dnf install mysql-community-server

# MySQLの起動
systemctl start mysqld

# 初期設定
mysql_secure_installation

my.cnfに以下のパラメータを追加

server_id= 1
gtid_#### mode= "ON"
enforce_gtid_consistency= "ON"
log_bin= "bin_log"
sync_binlog= "1"

MySQL再起動

systemctl restart mysqld

レプリケーション用のユーザーを作成

CREATE USER 'replication_user'@'192.168.0.0/23' identified with mysql_native_password by 'password';

作成したアカウントにREPLICATION SLAVE 権限を追加

GRANT REPLICATION SLAVE ON *.* to 'replication_user'@'192.168.0.0/23';

IDCF RDB(レプリカ)側

ネットワークを選択してRDBを作成(今回はvoltを使用)

以下のパラメータを追加したパラメータグループを作成

server_id= "2"
gtid_mode= "ON"
enforce_gtid_consistency= "ON"
log_bin= "bin_log"
sync_binlog= "1"
super_read_only= "1"
log_slave_updates= "1"
relay_log_recovery= "1"
relay_log_purge= "1"

作成したパラメータグループをRDBに適用

CHANGE MASTER TOの設定

CHANGE MASTER TO
MASTER_HOST="192.168.2.83",
MASTER_USER="replication_user",
MASTER_PASSWORD="password",
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;

レプリカのRDBでスタティックルーティング機能を使用しルーティング設定を追加

192.168.2.83/32 via 192.168.1.254

レプリカのRDBでレプリケーション開始

start slave;

レプリケーション確認

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.2.83
                  Master_User: replication_user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: bin_log.000001
          Read_Master_Log_Pos: 1384
               Relay_Log_File: rdb-90d8a3a5-f0b5-4a05-800c-bc2039fc16f0-relay-bin.000003
                Relay_Log_Pos: 1595
        Relay_Master_Log_File: bin_log.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1384
              Relay_Log_Space: 1839
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: 761ed903-9cf2-11eb-a50c-020223a50004
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 761ed903-9cf2-11eb-a50c-020223a50004:1-4
            Executed_Gtid_Set: 761ed903-9cf2-11eb-a50c-020223a50004:1-4
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 0
            Network_Namespace:

最後に

今回はIDCFクラウド内の別リージョンに構築した仮想マシンとIDCFクラウド RDBを使用してレプリケーションを組んでみましたが、バーチャルブリッジを利用してIDCフロンティアのデータセンターとIDCFクラウド RDB間でのレプリケーションを組むこともできます。 IDCFクラウド RDBでは外部サービスとのレプリケーションを組める仕組みなども検討予定ですのでご期待ください！！

こんにちわ。ITシステム本部の加藤です。イベント中はハンドルTenForward（@ten_forward）で紹介されていました。

6/11（金）にオンライン開催された『Infra Study 2nd #2「クラウドネイティブを支えるインフラ技術」』というイベントで少しお話をしてきましたので、そのイベントのレポートをしたいと思います。ここではメインの講演のみ紹介しますが、他にもLTがあり、そちらも勉強になりました。

この"Infra Study"というイベントはForkwellさんが主催されており、これまでのいずれの回も知らない人はいないであろう、国内トップレベルのインフラエンジニアが登壇していました。

私はこれまですべての回を聴講しています。どの回もかなりの盛り上がりを見せる、インフラエンジニアであれば知らない人はいないと言っても過言ではないようなイベントです。

まさか自分に登壇のお誘いがくるとは思っていませんでした! しかも第2回はクラウドネイティブ界隈では知らない人はいないであろう青山さん（@amsy810）のご紹介で、ストレージのスペシャリスト坂下さん（@ysakashita3）、データベースのスペシャリストこばさん（@tzkb）と一緒の登壇でした。大規模で著名なイベントですし、他の登壇者の方もすごい方ばかりなので、いつも以上に準備に時間をかけて臨みました。

このイベントはアーカイブ動画が公開されていますので、まだご覧になっていない方はぜひご覧になってください!

• https://www.youtube.com/watch?v=poQ-Yf0PtME

また、当日のTwitterでの盛り上がりは、当日登壇者でもあるこばさんがまとめてくださっています。

• https://togetter.com/li/1730969

最初に青山さんが私を含めた登壇者全員を紹介して、登壇者全員のハードルを上げた所で本編が始まりました。

コンテナの歴史を追いながらいまいちどコンテナについておさらいしてみる / 加藤泰文

speakerdeck.com

トップバッターは私でした。長ったらしいタイトルですね。適当に決めた仮タイトルがそのまま正式タイトルになってしまいました。

事前に紹介者である青山さんから私に期待する内容をおうかがいして、仮想化の歴史を追いながら、なぜコンテナがこれほど注目されるようになったのかという流れをお話すれば良いのかな、と理解して内容を考えました。

ただ、私は仮想マシンについては歴史を語れるほどの知見はないので、そこは軽く触れながらコンテナに関係する機能が実装されてきた歴史を追い、キーとなる技術を説明するような内容にしました。

そうは言っても20分で1970年前半からの歴史と技術の詳細を語るのは無理なので、いくつか選択した技術に限って少しだけ中身を説明し、その他の技術は名前を順に紹介するだけの軽めな内容になりました。

この登壇では、ちょうど私が昨年1年間開発に関わった「IDCFクラウド コンテナ」のサービスリリース直後ということもあり、その宣伝も行いながら、なんとか20分を少し超えるくらいでまとめることができました。

この記事をご覧いただいているみなさま、改めてIDCFクラウド コンテナをよろしくお願いいたします（^^）。

VM時代からコンテナ時代へストレージ管理の移り変わり / 坂下幸徳氏

speakerdeck.com

2番目の講演は坂下さんによるコンテナとステートフルアプリ、ストレージとの関係に関するお話でした。

「コンテナはステートフルアプリが苦手」という話を良く聞いたりします。それが実際どうなのかを、運用、ストレージがVMやコンテナからどう使われるのか？という説明を図示しながらわかりやすく説明されていました。

これは、おもに３つの観点からお話をされていたと思います。

まずはひとつめ。2020年には、55%のユーザーがコンテナでステートフルアプリをプロダクションで利用しているというCNCFによる調査があるようで、すでに「コンテナでステートフルアプリなんてありえない」という時期は過ぎたという説明がありました。

ふたつめは、Cloud Native な運用の考えから、コンテナでステートフルアプリを動かす際の考え方を説明されていました。ここが圧巻でした。この部分はTwitter上でも「この考え方はすごい」「この視点で見たことはなかった」と声が多数上がっていたところです。

稼働率の視点からステートフルアプリを見たとき、クラウドネイティブなシステムを前提とすれば、自動化によりメンテナンス時間が短縮できる。また、セルフヒーリングによる復旧時間の短縮も図れる。発想を転換して、メンテナンスや障害による停止の回数は多くても停止時間が短いシステムを前提とするならば、クラウドネイティブやコンテナの恩恵を受けたステートフルアプリが運用できるのではないか、というお話でした。つまり、クラウドネイティブなシステムを前提として設計すれば、トータルとしての稼働率は確保できるということですね。

最後に、ベアメタル、VM、コンテナからストレージを使う際の仕組みを取り上げ、図を使ってわかりやすく説明しながら、コンテナからストレージを使う際のメリットを考察していました。コンテナからストレージを使う場合の構成は、ベアメタルからストレージを使う場合の構成とほぼ同一で非常にシンプルである。途中にハイパーバイザーが挟まりその影響を考慮する必要があるVMに比べて、パフォーマンス面でも有利というお話を、ドライバがどこで動くかなどの説明も交えながらわかりやすく説明されていました。

最後に、

• 「コンテナはステートフルアプリが苦手」「コンテナのステートフルアプリはVMに比べて大変」というのは間違い
• （コンテナだから苦手なのではなく）「ステートフルアプリはステートレスアプリに比べると大変」というのが正しい
• ベアメタル、VMに続いて、コンテナでステートフルアプリを動かすという第三の選択肢が生まれたのだと見るべき

とまとめられていました。

その豊富な知識と経験から得られた的確な指摘とわかりやすい説明は本当に勉強になりました。上記の説明だけでなく、コンテナからストレージを使う際の仕組みや最新動向のお話もあり、とても密度が濃い20分だったと思います。

クラウドネイティブ時代のデータベース / こば氏

speakerdeck.com

3番目の講演はデータベース・ソムリエ、こばさんによるCloud Native時代のデータベースのお話でした。

現在から将来に至るクラウドネイティブ時代のデータベースを理解するために、段階を踏んで説明がありました。

まずは私は普段あまり意識しないRDBMSの内部コンポーネントについての説明から始まりました。RDBMS内部には多数のコンポーネントがあり、そのデータ管理を行うのがストレージエンジンと呼ばれる部分で、それを多数のノードに分散させようとすると難しいというお話です。

次に、ストレージエンジンが使うデータ構造が、ストレージとして使われるメディアがHDDからSSDへと変化していくにつれ、そのメディアの特性に合ったデータ構造への変化していっているというお話がありました。さらにNVMへの変化に対応するために、それに合ったストレージ構造に向けて色々と取り組みがあるようです。

そして、トランザクションを分散させると、それぞれの処理を時系列に並べることが難しくなる。それを解決するためにシングルリーダーにすると拡張性が失われる。そこで可用性と拡張性を同時に実現させるために、マルチリーダにして、Raftなどの合意プロトコルで同期を行うというお話がありました。

最後に、クラウドネイティブ時代のデータベースとして、ここまでの話で説明があった、新しいデータ構造、合意プロトコル、分散トランザクションを組み合わせたGoogle Cloud Spannerや、その類似の実装を行った分散データベースが生まれてきているとのことでした。

今後も新しい技術が使われるようになると、それに合わせてそれまで使われてなかった技術が導入されて、また新しいデータベースが生まれてくるかもしれないので、今後も引き続きウォッチしていきましょう、というお誘いで講演が終了しました。

「今日はちょっと細かい話をします」と言いながら、非常にわかりやすく、最後のまとめに導いていくところがさすがでした。そしてデータベースのデータ構造に、ストレージの技術が関係しているという所は結構目からウロコで、データベースからストレージまで、広い知識をお持ちのこばさんならではの解説で非常に勉強になりました。ゆっくりとわかりやすい口調の説明だったのも印象的でした。

感想

以上のように、20分の講演が3本と、それぞれの講演時間は短いイベントでした。しかし、私以外のお二人の講演は20分であることを感じさせない内容の濃さと、その濃さとは相反するような聞いているだけでスッと頭の中に入ってくる素晴らしい講演でした。

お二人とも、すごく細かい話に入っていって、私は聞いていて「え? 今からこれ説明始めて20分で終わるの?」と思ったりしました。しかし、終わってみるとしっかり理解もでき、短時間でわかりやすくまとまっていました。やはり各分野における第一人者は、広い範囲から必要な事を取捨選択してまとめる技術を持っているんだなと感心しました。

聞いていながら、「私ももっと勉強していかないとダメだな」という気分になるお二人の講演でした。そういう意味でも、今回このような素晴らしいイベントでお話ができたのは非常に刺激になりました。聞いた話で勉強になったのはもちろんのこと、それ以上に得るものが多かったイベントだったと思います。素晴らしいお話を聞かせて下さった、坂下さん、こばさん、ありがとうございました。

この記事を読んでいて、まだこの回をご覧になってない方は、すぐに見ないと損ですよ！

私が話している間のツイートをあとでさかのぼって拝見しました。非常に好意的に聞いてくださっている方が多かったようで、ホッとしました。ご参加のみなさま、ありがとうございました。

このような機会を下さった青山さん、Forkwellのみなさんをはじめとする運営の方々に改めて感謝の意を表したいと思います。ありがとうございました。

こんにちは、オペレーション本部サービス基盤部の伊藤です。

前回はオートロードバランスとヘルスチェックについて紹介させていただきましが、 今回は、それ以降 IDCFクラウド CDN に追加されたエンハンス機能やアップデートについてご紹介していきたいと思います。

これまでより便利に使える機能が追加されていますので、ぜひご利用いただければと思います。

便利なサンプルスニペットが追加されました！

VCLスニペットをより便利に活用するために、サンプルとなるスニペットが大幅に追加されました。
これにより、様々なカスタマイズを容易に実現することが可能になります。

追加されたサンプルは以下です。

• 巨大ファイルをキャッシュする
  →セグメントキャッシュの機能を利用し、動画ファイル等の巨大なファイルサイズのキャッシュが可能になります。
• 特定のパス配下をキャッシュさせない
  →/example1等、特定のパス配下にキャッシュさせたくないコンテンツを配置することで、キャッシュさせたいコンテンツと区別させることが可能です。
• 特定の拡張子をキャッシュさせない
• URLに特定の文字列を含む場合にキャッシュさせない
• 日本以外からのアクセスは403を返す
• 特定のパス配下のアクセスは404を返す　　

途中から解説を省いてますが手抜きではありません。
ほぼ解説の必要がないほどに、名前でどんなサンプルなのかが想像できるのも魅力のひとつです。

• 画像の加工方法を一括で指定する
  →イメージオプティマイザーサービスのみで使用可能です

こちらは少し解説が必要ですね。
通常、イメージオプティマイザーで配信される画像を加工する際、URLにクエリストリングスを付与する必要があります。
例) 画像の幅高さを200pixel で固定する場合
https://example.com/img/sample.jpg?width=200&height=200

このサンプルスニペットを使用すると、VCLスニペットによって内部的に画像処理を施してくれるため、クエリストリングスを付与しなくてもよくなります。

上記の例で言いますと、デフォルトで生成される以下のVCLスニペットを適用することで (https://example.com/img/sample.jpg) にアクセスするだけで幅高さが200pixelに統一できるという訳です。便利ですね。

if (req.url ~ "^/img/"){
  set req.url = querystring.add(req.url, "width", "200");
  set req.url = querystring.add(req.url, "height", "200");
}

キャッシュ削除がより使いやすくなりました！

Fastlyを基盤としている IDCFクラウド CDN はキャッシュ削除の速さが売りのひとつですが、これまではURLを直接指定する「URL削除」と、すべてのキャッシュを削除する「すべて削除」を使用されるケースがほとんどでした。

実はこれに加え、より便利な「まとめて削除」という機能があるのですが、ご存知だったでしょうか。

この機能は、「1個1個URL指定でキャッシュ削除するのは面倒臭い」「といってすべて削除したい訳じゃない」といったニーズに応えるものになっております。
もう少し具体的にいうと、特定のディレクトリ配下すべてのファイルをキャッシュ削除したい、特定の拡張子または特定のファイル名で指定してキャッシュ削除したい、といったケースに対応可能です。

まとめて削除の画面UIはこのようになっています。

入力欄にディレクトリやファイル名・拡張子をワイルドカードと絡めながら指定していきます。
入力例も詳しく載っていますので、迷うことなく使える UI になっているかと思います。

入力例

• ディレクトリ配下のすべてのファイルのキャッシュを削除する場合：/foo、/foo/bar
  ※ディレクトリ配下のディレクトリ内のキャッシュも削除されます。/foo/* を指定した場合には/foo/bar/配下のキャッシュも削除されます。
• 同一拡張子で削除する場合：/foo/*.png
• 同一ファイル名で削除する場合：/foo/example.*
• 複数指定（半角スペース区切り）：/foo /bar

技術的にはサロゲートキー(キャッシュキーともいいます)を応用したものになります。 詳しくは、Yamgoya 2019で弊社 浅沼が登壇してしておりますので、ご覧ください。

vimeo.com
12:32 あたりから

こちらの機能は、本家 Fastly では提供していない IDCFクラウド CDN 独自の機能となっておりますので、ぜひご活用いただければと思います。

UIからキャッシュ確認ができるようになりました！

これまで、正常にキャッシュが行われているかどうかを確認するためにはブラウザの検証機能を利用したり、直接 curl コマンドを打って確認するほかありませんでした。
それを UI から簡単に可能にしたのが本機能になります。
確認方法につきましては、ご利用ガイドをご覧いただければと思います。

本家 Fastly にもキャッシュ確認機能の UI はございますが、IDCFクラウド CDN 独自に以下の機能が追加されております。

• 検索機能
  フリーワード、もしくはステータス(HIT, MISS)での検索が可能です。
• 確認結果のダウンロード
  確認結果を JSON 形式でダウンロードすることが可能です。
  ※検索機能で絞った状態でも、キャッシュ確認結果のすべてがダウンロードされますのでご留意ください。
• キャッシュキー
  キャッシュキーを確認することが可能です。前述した「まとめて削除」に、このキャッシュキーを指定することができるため、より便利に利用することが可能になります！

最後に

いかがでしたでしょうか。
今回ご紹介した機能は、以前からのお客様の要望を実現したものであったり、使いこなせば便利だが、使い方がわかりにくく埋もれてしまっていたものがフォーカスされております。
いずれも便利な機能だと思いますので、ぜひご利用いただければ幸いです。

IDCFクラウド CDN では、基盤である Fastly の強みを踏襲しつつ、独自の使いやすさやシンプルさを提供できるような開発を今後も目指していますのでご期待ください！

こんにちは、藤城（@tafujish）です。今回も「IDCFクラウド コンテナ」サービスについてです。
www.idcf.jp
IDCFクラウドでは、無料のロードバランサー （仮想ルーター）と高性能・高機能のインフィニットLBがあります。これらは、IDCFクラウド コンテナと連携しています。一方で、KubernetesとしてはService Type LoadBalancerやIngressといった実装があります。これらがどのように連携して、どのような用途でどのロードバランサーを選択するのがよいか紹介します。

IDCFクラウドで利用するロードバランサーの選び方

ここでは、IDCFクラウド コンテナ for IDCFクラウド（IDCFクラウド コンピュートサービスにKubernetesクラスターを作成する）における、ロードバランサーの選択肢とどのように選択するかを紹介します。まとめると次の表のようになります。

対応	Kubernetes側	IDCFクラウド側	特徴
L4	Service Type LoadBalancer	仮想ルーター	無料のロードバランサーをコンテナサービスでも同様に利用可能で、3240GBの転送量無料分も付きます。UIから直接設定可能で簡単に使い始められます。
L4	Service Type LoadBalancer	インフィニットLB	仮想ルーターを超える処理性能が必要な場合は、インフィニットLBに置き換えることも可能です。
L7	Ingress	インフィニットLB	SSLターミネーションやパスパターンによるバランシングなどの高機能と、オートスケールする処理性能を持ちます。UIから直接設定可能で簡単に使い始められます。
L7	Ingress	NGINX Ingress	どこのインフラ上でも動作可能なロードバランサーとして提供しています。ご利用のKubernetesクラスター上で動作するためロードバランサーを使うための追加費用は不要です。IDCFクラウド上の利用においても、複数の証明書によるSSLターミネーションなどといったインフィニットLBのコストインパクトが大きくなる場合は選択の候補となります。

4つ選択肢はありますが、よく使うものは2つです。
1つは、簡単にはじめられて低コストで利用できるService Type LoadBalancerの仮想ルーター。

もう1つは、高性能や高機能を必要とする場合にIngressのインフィニットLB。

Service Type LoadBalancerとしては、高性能を目的にインフィニットLBも選べますが、Ingressから利用する方がUIの操作性や今後の拡張を考えると良いです。Kubernetesクラスターの内部で更にバランシングするといった構成の場合は、シンプルな構成を組めるのでService Type LoadBalancerでインフィニットLBを使うケースもあります。

Ingressとしては、NGINX Ingressも選べますが、IDCFクラウドで利用する場合はインフィニットLBがより便利です。コスト的な問題があり、スケール性が必要ない場合は利用するケースもあります。

こんにちは、藤城（@tafujish）です。IDCFクラウド コンテナのロードバランサーについて前回の続きを書く予定でしたが、10月5日にリリースしたCentOS8互換のOSテンプレートについて先に取り上げさせていただきます。

今回、IDCFクラウドのOSテンプレートとして、以下の3つをリリースしました。

• AlmaLinux 8.4 64-bit
• MIRACLE LINUX 8.4 64-bit
• Rocky Linux 8.4 64-bit

CentOS8が2021年末で終了の発表があってから、CentOS8に替わる様々なLinuxディストリビューションがリリースされ、お客さまからも多くのご要望をいただきました。お客さまが利用する際に迷わないように、CentOS8の後継として一つに絞って提供しようとこの半年間検討を続けてきましたが、2021年末のCentOS8終了が差し迫った状況ですので、ご要望に添い3つリリースとしました。そこで今回は、お客さまからの声や案件の状況を共有することで、利用するOSを選ぶ際の一助となればと思っています。

こんにちは、藤城（@tafujish）です。前回↓の続きで「IDCFクラウド コンテナ」のロードバランサーについてです。

blog.idcf.jp

前回は、IDCFクラウド コンピュート上でコンテナサービスを利用するときに利用できる4つのロードバランサーを紹介しました。今回は、それぞれの設定方法や仮想マシン含めたネットワーク構成がどうなるか紹介していきます。

kind: Service
apiVersion: v1
metadata:
  name: nginxtest-ilb
  annotations:
    loadbalancer.idcfcloud.com/loadbalancer-class: "ilb"
spec:
  type: LoadBalancer
  selector:
    app: nginxtest
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

こんにちは。 UI/UXデザイナーの関です。 IDCFクラウドのUI設計やユーザーリサーチを担当しています。
今回はIDCFクラウドのサービスの１つであるコンピュートについてFAQのアクセス分析からIDCFクラウドのUI改善へ繋げたお話をさせていただきます。

分析の目的

UIを改善するにあたって必要なのはユーザーを知ることです。
ユーザーの利用状況を理解して、つまづきそうなポイントがあれば先回りして回避することがユーザービリティ向上に繋がります。
そうしたユーザー理解なしに改善を行うと場当たり的な改善を繰り返すだけの運試し要素が強くなってしまいます。
とはいえ、弊社のようなBtoBサービスでは気軽にユーザーに話を聞きにいくのはハードルが高めなので、それ以外のタッチポイントからユーザー理解の根拠となるデータを集めないといけません。

そこで今回取り組んだのがFAQコンテンツのアクセス分析です。
詳細は後述しますが、疑問を持ったユーザーが集まるFAQコンテンツのアクセス状況を分析し、疑問の傾向を把握することで効果的なUI改善に繋げるという取り組みです。

収集したデータの整理

まずGoogleAnalyticsでコンピュートに関連するFAQの年間アクセス数を調べました。
そこからUIの改善に繋がりそうな「UIの操作に関するFAQ」と「用語に関するFAQ」のみをピックアップし、カテゴリー分類を行います。
ここでカテゴリー分類を行う理由は各FAQに対応するUIの改善といった局所的な視点だけでなく、どのようなカテゴリーのFAQがアクセス多く集めているかという全体的な視点から課題を認識するためです。

アクセス数順に並び替えたら、アクセス数を元に改善対象となるFAQの対象を絞り込み、次のような視点から具体的な改善施策を考えていきます。

• 各FAQの内容からUI上でどのようなヒントがあれば解決できるか？
• どのような画面設計であればユーザーを迷わせないか？

そこから各改善施策の優先度を決めて、実行フェーズへと移行します。
この際の優先度はアクセス数が多いほど優先度が高いのはもちろんですが、工数がどれくらいかかるかも加味して決定します。

具体的な改善施策を検討

ここからは具体的なユーザー傾向や改善施策を紹介していきます。

下の表がFAQのアクセス数の全体像です。
こうしてみると「ボリュームの拡張（リサイズ）手順を教えてください。」のアクセス数が圧倒的に多く、ボリュームの拡張のやり方に問題を抱えているユーザーが多そうです。

具体的な改善施策の一例として最もアクセス数が多かった「ボリュームの拡張（リサイズ）手順を教えてください。」を取り上げます。

FAQの内容を見をみると手順自体はそこまで迷うような複雑さはなさそうです。
なので、ボリュームの拡張に至るまでの過程に問題はないか見ていきます。
そうすると、仮想マシンにアタッチされていない場合、ボリュームの拡張ができずツールチップで「Allocatedのボリュームでは実行できません。」と表示されます。
これだけだと、どうやらリサイズはできなさそうだということは分かっても、ここからどうしていいのか分からないなのでツールチップ上で必要なアクションを記載するようにしました。

このように画面設計において、ユーザーを袋小路に陥らせないことは画面設計での重要な要素です。
今回紹介した改善施策はあくまで一例ですが、ニーズの高いFAQの内容をヒントにして、画面間の導線改修やツールチップの拡充、FAQやご利用ガイドなど外部のヘルプコンテンツへの誘導など色々な施策を打ち立てました。

一方でカテゴリーを見てみるとスナップショット関連のFAQにアクセスが多く、スナップショットに関する一連の操作に課題を抱えているユーザーが多そうです。
個別のFAQに対してUI改善は行うだけではなく、スナップショットの包括的な理解を促すこともニーズが高そうです。
IDCFクラウドのご利用ガイドを見てみるとスナップショットのガイドがなく*、ガイドを作成してIDCFクラウドから導線を設ければ包括的な理解を促進することができそうです。

*現在はスナップショットのご利用ガイドは設置されています。

まとめ

分析してみると色々なことが分かるもので、アクセス数だけではなく、FAQの次の遷移先や参照元、平均滞在時間等の指標と照らし合わせることで色々なことが見えてくるので奥が深いです。
今後は以下のような視点を持って、定期的にPDCAを回して更なる改善を図っていきたいと思います。

• 改善の結果、FAQのアクセス数がどう変化したか？
• これまで見られなかった新たな課題はあるか？

こんにちは。事業推進本部SE部の横田です。
今回はIDCFクラウド コンテナサービスにおけるオートスケールについて紹介します。

• 背景と目的
  • 前提条件
  • 構成イメージ
    • 基本構成
    • ワークロードのオートスケール時のイメージ
    • Workerノードのオートスケール時のイメージ
• 環境確認
  • クラスタの設定確認
  • クラスタID、ノードプールIDの確認
• 環境設定
  • API & キー
  • カタログの追加
  • cluster-autoscaler の設定
    • 名前空間
    • CLUSTER AUTOSCALER IMAGE REPOSITORY IMAGES SETTINGS
    • CLUSTER AUTOSCALER DEPLOYMENTS SETTINGS
    • CLUSTER AUTOSCALER SETTINGS
    • CLUSTER AUTOSCALER SETTINGS (TARGETNODEPOOLS)
  • cluster-autoscaler ステータスの確認
  • cluster-autoscaler ワークロードの確認
  • HPA（Horizontal Pod Autoscaler）設定
    • テスト用ワークロードのデプロイ
    • HPA設定
• 動作テスト
  • 宛先アドレスの確認
  • 負荷テスト
  • ワークロードのスケールアウト
  • ステータス確認
  • Workerノードのスケールアウト
  • ワークロードの確認
  • ワークロードのスケールイン
  • Worker ノードのスケールイン
• まとめ

背景と目的

IDCFクラウド コンピュートではオートスケールの導入は手間がかかりますが、実はコンテナサービスではノードのオートスケール機能が簡単に使えます。
本稿では以下の内容について記載していますので、是非ご参考にしてください。

• ワークロードのオートスケール利用方法
• Worker ノードのオートスケール利用方法

前提条件

• Kubernetes のバージョンが 1.19 以上であること
• クラスタの構成が Master ノードと、Workerノードで分離されていること

構成イメージ

スケールアウト時の状態遷移イメージは以下の流れになります

1. 基本構成
2. ワークロード オートスケール
3. Worker ノード オートスケール

基本構成

初期状態として Podは最小の1台です。

ワークロードのオートスケール時のイメージ

負荷を掛ける事で、Podが自動的にスケールアウトされます。

Workerノードのオートスケール時のイメージ

ワークロードがスケールアウトされる時にノードのリソースが不足した場合、Worker ノードが自動的にスケールアウトされます。

環境確認

オートスケール環境を作っていきます。

クラスタの設定確認

クラスタの構成が前提条件を満たしているか確認します。

• master ノードと worker ノードで分離されていること
• Kubernetes のバージョンが [v1.19] 以上であること

※worker ノードは worker の役割のみである必要があります。

クラスタID、ノードプールIDの確認

cluster-autoscaler 設定を行う際に必要な情報を確認します クラスタから「ノード」を開き、worker ノードに割り当てられているIDを確認します。

• cluster id：c-xxxxx
• node pool id：np-xxxxx

※今回はノードプールの指定は行いませんが、スケール対象としてノードプールが指定可能です。
　ノードプールを指定する場合はノードプールIDも確認しておきます

環境設定

ここから オートスケールの設定手順を紹介します。
ここでは CPU使用率を元にオートスケールする設定を行っています。

API & キー

画面右上のアイコンから「API & キー」をクリックして APIキーを追加します。

• 詳細情報：任意の名称
• 自動での失効日設定：しない
• スコープ：スコープなし

作成された APIキーの情報をメモ帳等に控えておきます。

カタログの追加

1. 画面左上から、「Default」プロジェクトを選択
2. 「ツール」>「カタログ」をクリックします
3. 「cluster-autoscaler」をクリックします

cluster-autoscaler の設定

cluster-autoscaler カタログの設定を行っていきます。
以下では必要最低限のみ設定を行っています。

名前空間

• 名前空間：default
• Helm Wait：変更なし
• Helm Timeout：変更なし

CLUSTER AUTOSCALER IMAGE REPOSITORY IMAGES SETTINGS

• Image：変更なし
• Image Tag：変更なし
• ImagePullPolicy：変更なし

CLUSTER AUTOSCALER DEPLOYMENTS SETTINGS

• Deployments Replicas：変更なし
• Scan Interval：変更なし
• klog Verbose level：変更なし
• Rancher Client Debug：変更なし

CLUSTER AUTOSCALER SETTINGS

• ClusterId：c-xxxxx※「事前確認」で確認したクラスタIDを入力します
• API URL：変更なし
• Token Key：APIキー作成時の "Bearer トークン"※「API & キー」で作成した「Bearer トークン」を入力します。
• Min Size(Common)：3
• Max Size(Common)：6

※今回は最小台数３，最大台数６　として設定を行います。

CLUSTER AUTOSCALER SETTINGS (TARGETNODEPOOLS)

• NodePool Name：変更なし
• Min Size：変更なし
• Max Size：変更なし

※今回はノードプールでの指定は行いません。

cluster-autoscaler ステータスの確認

cluster-autoscaler 作成完了後、状態が「Active」であることを確認します。

cluster-autoscaler ワークロードの確認

ワークロードから cluster-autoscaler のワークロードが作成されている事を確認します。

HPA（Horizontal Pod Autoscaler）設定

テスト用ワークロードのデプロイ

テスト用に phpinfo が確認出来る pod を用意します。

作成時に詳細設定から 「CPU予約」を 1000 ミリCPU としてデプロイします。 ※1000ミリCPU を指定することで 1コア予約されます。

HPA設定

プロジェクト「Defautl」から「リソース」>「HPA」をクリックします。

「HPA を追加」をクリックします。

「水平ポッドオートスケーリングを編集」から設定を行います。
※今回はHPAの対象として、先ほど作成した「テスト用ワークロード」を指定しています

• 名前：phpinfo※任意の名称
• 名前空間：deault※オートスケールさせたいワークロードが存在する名前空間を指定
• ワークロード：phpinfo※オートスケールさせたいワークロードを指定
• 最小レプリカ数：1
• 最大レプリカ数：20

メトリック値を設定します

• メトリックタイプ：リソース
• メトリック名：CPU
• ターゲットタイプ：平均使用率
• 数量：10※今回スケールアウトしやすいように特別小さい値「10％」としていますが、実際のシステムでは、どれくらい余裕を持たせてスケールさせるか値を設定してください

作成したHPA設定が「Active」であることを確認します。

動作テスト

負荷を掛け、Podがスケールアウトし、リソースが足りずノードがスケールアウトされることを確認していきます。

宛先アドレスの確認

デプロイしたワークロードから宛先アドレスを確認します。

負荷テスト

クラスター環境外にある仮想マシンから wrk コマンドを利用した負荷テストを行っていきます。
※wrk コマンドのインストールについては本稿では言及していません。

以下のパラメータで負荷を与えます。
※環境によってはパラメータを適宜変更してテストしてください。

• スレッド数：4
• コネクション数：100
• タイムアウト：300
• URL：http://xxx.xxx.xxx.xxx

wrk -t4-c100-d300 http://xxx.xxx.xxx.xxx/
Running 5m test @ http://xxx.xxx.xxx.xxx/
  4 threads and 100 connections

ワークロードのスケールアウト

ワークロードに負荷を掛ける事で、Podがスケールアウトされることを確認します。

ステータス確認

Pod が一定数スケールアウトされると、途中からスケールアウトされる Pod のステータスが「Scheduling」になることを確認します。
※cluster-autoscaler では「Scheduling」ステータスをトリガーに、ノードのスケールアウトを行います。

Workerノードのスケールアウト

「クラスタ」>「ノード」から、worker ノードが追加されている事を確認します。
※以下イメージ図では、worker-4,5,6 が追加され、環境準備中の状態となります。

順次、ステータスが「Active」になることを確認します。

ワークロードの確認

リソースが足りず、スケールアウトできなかった Pod が正常にデプロイ、起動している事を確認します。

ワークロードのスケールイン

5分後 wrk コマンドが完了している事を確認します。

wrk -t4-c100-d300 http://xxx.xxx.xxx.xxx/
Running 5m test @ http://xxx.xxx.xxx.xxx/
  4 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   187.79ms  220.17ms   2.00s    84.12%
    Req/Sec   125.1364.59474.0063.47%
  124746 requests in5.00m, 51.43GB read
  Socket errors: connect 0, read185, write 3, timeout 256
Requests/sec:    415.67
Transfer/sec:    175.50MB

wrk コマンドが完了すると、ワークロードの負荷が下がり、スケールインが行われます。
Pod の数が元の「１」個になっている事を確認します。

Worker ノードのスケールイン

一定時間後、Worker ノードがスケールインされます。
※スケールインが開始されるまで約10分程度かかります。
Worker ノードが元の状態 [3台] になっている事を確認します。

まとめ

今回は コンテナサービスにおけるオートスケールの利用法について紹介させていただきました。
IDCFクラウドも早くオートスケールが利用できるようになればいいですね！

コンテナサービスの利用、活用法については 他のメンバーからも投稿予定がありますのでご期待ください！

こんにちは。事業推進本部SE部の横田です。

今回は 2022年3月14日に発表された Google Cloud (GCP) の料金改定について、IDCFクラウド に与える影響について纏めたいと思います。 ※料金改定は 2022年10月1日から適用されます

cloud.google.com

• 料金改定の対象
• クラウドストレージ 料金改定の内容
  • ストレージ料金
  • オペレーション料金
  • リージョン間レプリケーション料金
  • 下り（外向き）ネットワーク料金
• さいごに

料金改定の対象

今回の料金改定で対象となるサービスは以下の4点となっています。

• Cloud Storage
• 永続ディスクのスナップショット
• Cloud Load Balancing
• モニタリングサービス

IDCFクラウドで影響を受けるのはクラウドストレージとなりますので、本稿では クラウドストレージでの変更点を取り上げます。

クラウドストレージ 料金改定の内容

Regional、 Nearline で利用されている場合には影響ありませんが、Coldline、 Multi-Regional では料金が変更になります。

ストレージ料金

ストレージ料金は影響ありません。

オペレーション料金

オペレーション料金に関しては、以下3点で値上げとなります。
※10,000オペレーションあたりの料金

リージョン間レプリケーション料金

Multi-Regional において、書き込まれたオブジェクトを別のリージョンに自動で同期するレプリケーション処理に対して新たに料金が設定されました。

下り（外向き）ネットワーク料金

Google Cloud サービスから読み取る際の下り（外向き）トラフィックに対して新たに料金が設定されました。

cloud.google.com

さいごに

今回は IDCFクラウド で提供しているクラウドストレージ を対象とした料金改定を整理してみました。

おまけとして今回の料金改定全体の内容を以下の表にまとめてみましたのでご参考いただければ幸いです。
※データ量、オペレーション、データレプリケーションのみで 下り転送量については含まれていません。

こんにちは、藤城（@tafujish）です。2021年10月にIDCFクラウドでのCentOS8互換のOSテンプレートについて取り上げ、Rocky、Alma、MIRACLEの3種類をリリースしたことを案内しました。

blog.idcf.jp

この時はCentOS8のEoLを想定しておりましたが、現在ですと2024年6月に迫ったCentOS7のEoLを見据えて採用OSを改めて選定しているという話を聞くようになってきました。そのなかで、IDCFクラウドはどのOSを採用するのかという質問をいただくことがしばしばありました。結論から言うと、Rocky Linuxを選びましたので、本日はその背景をご紹介いたします。

こんにちは、藤城（@tafujish）です。「IDCFクラウド コンテナ」で利用可能な4つのロードバランサーについて以前に紹介しました。

blog.idcf.jp

この中の一つ、L7のNGINX Ingressが思っていた以上にニーズがあったので、改めて使い方を紹介したいと思います。具体的には以下のようなケースだとNGINX Ingressが有用です。

• IDCFプライベートクラウドやオンプレミス（カスタム）などのIngressが標準で実装されていない環境でのL7ロードバランサー
• IDCFクラウドコンピュートで大量の証明書を利用したいとき（インフィニットLBだと利用料が高額になってしまう）

それでは、実際の設定の流れを見てみましょう。

クラスターでの事前設定

まずはクラスターにて、NGINX Ingressの機能を有効化します。クラスター作成時、またはクラスターの「設定を編集」にて

拡張オプション内の「イングレスプロバイダー」を「有効」にします。

なお、IDCFクラウドコンテナ for IDCFプライベートクラウド と for カスタム（オンプレミス）ではイングレスプロバイダーはデフォルトで有効になっています。for IDCFクラウドでは、インフィニットLBが標準で利用できますので、イングレスプロバイダーはデフォルトで無効になっています。後から、有効・無効の変更も可能です。

イングレスプロバイダーを有効にするとSystem上で nginx-ingress-controller がActiveとなります。

以上で、クラスターの事前準備は終わりです。

キー: kubernetes.io/ingress.class
値: nginx

  ingressClassName: nginx

こんにちは、藤城（@tafujish）です。CData SoftwareさんがCData SyncのIDCFクラウド上での構築方法をブログに書いてくれました。ありがとうございます。

www.cdata.com

この機会に自分の方でも触ってみたので、IDCFクラウドでCData Syncを使うならではの構成を紹介したいと思います。ついでに、アドベントカレンダーにも参加させてもらおうと思います。

qiita.com

ssh -L 8181:localhost:8181 <USER>@<Public IP Address> -p <Port>

こんにちは。 UI/UXデザイナーの関です。 IDCFクラウドのUI設計やユーザーリサーチを担当しています。
「デザインシステム」という言葉を聞いたことがあるでしょうか？近年、多くの企業がデザインシステムを導入し、デザインの品質向上や生産性向上など、多くのメリットをもたらすものとして注目されています。

IDCフロンティアでもデザインシステムを導入し、IDCFクラウドのデザイン品質の向上や生産性の向上に取り組んでいます。

こちらでは、準備編と構築編の2部に分けて、デザインシステム導入プロセスの紹介、具体的な導入方法などを紹介していきます。デザイナーの方はもちろん、デザインシステム導入に興味がある方にも役立つ情報を提供していきますので、ぜひご覧ください。

デザインシステムとは何か？

デザインシステムは、プロダクト開発に必要なデザインの基礎である原則や概念を土台として、スタイル、UIコンポーネントライブラリ、コードルールなどをまとめたものです。デザインシステムにより、プロダクトのデザインに関する一貫性を確保し、品質や生産性を向上することができます。また、デザインチームや関係部署との協力やコミュニケーションをデザインシステムを介した共通の言語で行うことができ、コミュニケーションの質とスピードが向上します。

デザインシステムが必要になった背景

現在のIDCFクラウドのUIは表面上は統一感があるように見えますが、各サービスごとに改築が繰り返されているため、細かい部分ではまだ統一されていない箇所が多数存在しています。

さらにエンジニアとデザイナーの間で共通認識の基盤となる情報が十分に整備されていなかったため、コミュニケーションや効率に関する問題が発生していました。

これらの問題を解決するために、デザイナーとエンジニアが連携してデザインシステムを構築することになりました。

下の表でIDCFクラウドが抱えていた課題とそれに対応するデザインシステムの効果をまとめました。

デザインシステムの構築プロセス

デザインシステムの目的と目標の設定

今回、初めてデザインシステムを構築するにあたり、アラ・コルマトヴァ （著）,佐藤 伸哉 （監訳）『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』（ボーンデジタル、2018、p256）というガイドブックの内容をチームでまとめ、デザインシステムの基本を理解しました。

基本が理解できたところで、チーム内でIDCFクラウドのUIが抱える課題を明確にしました。その際、共通認識を持つためにワークショップ形式で課題の洗い出しを行いました。そこで出た課題の中からデザインガイドで解決できるものを抽出し、優先順位を付けました。

以下は、抽出した課題の一部です。

• どのパターンでどのパーツを使うかが明文化されていない
• 文字サイズが基本的に小さく、読みづらい箇所がある
• 同じ機能であるが、異なるUIパーツが存在する
• アプリケーション仕様を考慮した説明が欲しい（例：色の選び方）
• 表（table）の種類が多く、整理が必要
• コーディングスタイルが統一されていない

現状調査

上記の課題で挙げられたUIパーツの不整合に関して、現状の各UIパーツがどの程度の不整合性を抱えているかと、UIのユーザビリティ上の問題点を調査しました。

ユーザビリティ上の課題の大きさや不整合の解消への工数を考慮のうえ、今後の優先度を決定する材料として活用していきます。

以下は調査結果の一部です。

• 同じ意味を持つアイコンが複数種類ある
• ボタンのサイズがまちまち
• フォームのバリデーションチェックの挙動がバラバラ
• 日付の書式が揃っていない
• プレースホルダーの文言が統一されていない

UIの色や形といった大枠は揃っているものの、アイコンやボタンのサイズ、UIの挙動等の整合性はまだ課題があることが分かりました。

他社調査

そこから他社で公開されているデザインシステムを参考にし、他社がデザイン原則やデザイントークン及びコンポーネントをどのように定義しているかを調査しました。この調査でIDCFクラウドの現行のUI定義をブラッシュアップし、グループワークや現状調査では見落としていた課題を洗い出しました。

他社調査では色やフォントサイズのバリエーション、モーダルの適切な使用場面やテーブルの組み合わせパターンなど、デザインシステム構築だけでなく、今後のUI改善のヒントとしても大変参考になりました。

デザインシステムのリリース範囲を決定

現状調査や他社調査を通じて、徐々にデザインシステムに必要な要素が明らかになってきました。そこで、まず最初のリリースの範囲を決定しました。範囲の決定にあたっては以下の2つのポイントを重視しました。

1. 関係者にできるだけ早いタイミングで共有することを最優先とし、デザインシステム自体は必要最低限の要素で構築する
2. デザイントークンやプロダクト内で頻繁に使用されるコンポーネントなど、影響範囲の大きい要素から優先的に取り組むことで、効果的なデザインシステムの導入を目指す

デザインシステムの構成

リリース範囲の検討を経て、以下のような構成で第１弾となるver.１をリリースすることとなりました。

以上が準備編となります。

次の構築編では各構成の詳細や、デザインシステムの運用についてご紹介していきます。

デザインシステムの構築

こんにちは。 UI/UXデザイナーの関です。 IDCFクラウドのUI設計やユーザーリサーチを担当しています。
前回の記事では、IDCFクラウドのデザインシステム構築のための準備段階のお話と、大まかな構成についてお話させていただきました。今回はもう少し詳細に構築プロセスをご紹介します。

はじめにの定義

「はじめに」のセクションでは、デザインシステムの目的、デザイン原則、デザインポリシーなど、デザインシステムの基盤となる情報をまとめています。

その中でもデザイン原則は、デザインシステムの土台をなす部分であり、非常に重要な要素です。

デザイン原則とは、デザインシステムを利用して画面を作成する際に指針となる基本的な考え方や価値観のことを指します。

デザイン原則に基づいて、UIの見た目、挙動、組み合わせなどを決定していきます。既存のUIにとどまらず、新たなUIを追加する際もデザイン原則を基準に判断していきます。

デザイン原則の作成プロセスでは、できるだけ幅広く網羅的なアプローチを取るために、チームメンバーでグループワークを行い、現状分析や競合他社の調査結果を考慮しながら、デザイン原則を決定していきました。

グループワークで出た案の中から、簡潔でわかりやすいデザイン原則に絞り込むとともに、カバーしきれていない領域がないかも慎重に検討しました。また、IDCFクラウドのブランドアイデンティティや特長を考慮し、それらを反映させるようなデザイン原則を策定することを重視しました。

このプロセスを通じて、チーム全体で共有できる明確かつ包括的なデザイン原則を作成することができました。

デザイントークンの設定

デザイントークンは色やタイポグラフィなど、見た目や振る舞いに関する基本要素をまとめています。リリース範囲の検討の際に必要最低限の要素に抑えるとしましたが、デザイントークンの性質上、影響範囲が広く必要最低限とはいえボリュームが大きくなり、以下のような構成となりました。

• 色
• タイポグラフィー
• アイコン
• レイアウト
• シャドウ
• 角丸
• ロゴ

色

IDCFクラウド全体の一貫性を保つために、プライマリーカラー、セカンダリーカラーなど、各色の役割を定義し、それぞれのシチュエーションで使用すべき色を統一しました。

さらに、アクセシビリティの観点からも、達成すべきアクセシビリティ基準を設定し、コントラスト比にも注意を払いました。これにより、視覚的な障害を持つユーザーにも分かりやすいデザインが実現できます。

このような色の取り扱いに関するルールをデザインシステムに盛り込むことで、デザインの一貫性やアクセシビリティが向上し、開発者やデザイナーが迅速かつ効率的に作業を進めることが可能になります。

タイポグラフィー

タイポグラフィーでは、使用できるフォントの指定や、各見出しレベルやテキスト内で使用可能なサイズのバリエーションを定めました。実装時とデザインツール使用時の両方で参照しやすいように、各サイズはpxとremの両方で記載しています。さらに、各サイズにおけるline-heightやletter-spacingといった細かいスタイル設定も規定しています。これにより、デザインシステム全体でタイポグラフィーの一貫性が保たれ、デザイナーや開発者が効率的に作業を進めることができます。

アイコン

アイコンの使用を適切に制限するために、アイコンが必要とされるシチュエーションを明確に定め、アイコンの使用プロセスを整理しました。これにより、どのユーザーがアイコンを使用しても、目的に合ったアイコンを適切に配置できるようになりました。

コンポーネントの設計と開発

コンポーネントはボタン、ヘッダー、フォーム要素、メニューなどのUI部品を指し、それらの使い方や指針を定義しています。

コンポーネントの構築として、まず最初にIDCFクラウドで使用頻度が高いボタンとテーブルの定義から作成を始めました。ボタンに関しては、サイズや種類といった大まかな部分から、ボタンのラベルのルールやアイコンを使用する場合の指針といった細かい部分まで定義し、ボタンの仕様を統一しました。

さらに、混同しやすいテキストリンクとボタンの用途の違いをNGパターンを取り入れて解説しました。これにより、ルールに反した使い方を避け、一貫性のあるUIデザインを実現することができます。

テーブルに関しても、様々なパターンのレイアウトやスタイル、データの表示方法などを定義しました。さらにテーブルだけではなく、テーブルに付随するページネーションや表示件数の切り替えボタンや、検索窓などの操作エリアも定義し、様々な組み合わせパターンにも対応できるようにしました。

社内関係者への共有

構築が終わったら、実際にデザインシステムを利用するであろう社内関係者への共有を行いました。

さらに、関係者から普段の画面設計や実装において日頃直面している問題や困難な点をヒアリングしました。このフィードバックを元に、次回のデザインシステムのアップデートに取り組み、より使いやすく改善されたデザインシステムを提供することを目指しました。

以下は関係者から挙がった課題の一部です。

• IDCFクラウドには日本語サイトと英語サイトがあるが、同じUIにおいて日本語と英語で文字数が異なる場合に、どちらの言語に対応したデザインを採用すべきか判断に迷うことがある
• モーダルである必要がないと思われる箇所でもモーダルであることがあり、実装コストもかかるため必要最低限に抑えたい
• 電話番号や郵便番号のハイフンが画面によって、入っていたりいなかったりでどちらが正しいのか分からず迷う

このような情報共有とフィードバックのプロセスを通じて、デザインシステムがすべての関係者にとって有益で効果的になるように取り組んでいます。また、定期的なレビューやアップデートにより、デザインシステムが継続的に進化し、社内関係者のニーズに適応することを目指しています。

デザインシステムの今後

ここまでゼロからデザインシステムを構築し、共有までのプロセスをご紹介しましたが、もちろんこれで終わりではありません。コンポーネントも現段階では必要最低限のものしかカバーできていませんし、ワーディングルールやアクセシビリティポリシーといった新たな枠組みの追加も必要です。

さらに、デザインシステムは組織全体で適用され、継続的に改善されるべきものです。これを実現するためには、定期的なレビューやフィードバックの収集、そして新たなデザイン要素や技術の取り入れが欠かせません。また、組織内の異なるチームやプロジェクト間でのコミュニケーションが円滑に行われるよう、情報共有の仕組みも整えておくことが重要です。

今後もデザインシステムのアップデートを続け、より効果的なチーム連携と効率化を進めていきます。

こんにちは。事業推進本部SE部の横田です。

今回は先日リリースされた機能強化「Rootボリュームサイズのリサイズ」についてのご紹介です。
実際にクラウドコンソールからリサイズする流れや注意事項、OS上から利用できるまでの手順を紹介したいと思います。

www.idcf.jp

• 前提条件
• クラウドコンソール操作
  • リサイズ出来ない場合
• CentOS での反映
• Windows Server での反映
• まとめ

前提条件

• 既に作成済みの仮想サーバーが対象
• 仮想サーバーが停止していること
• 100GB までの拡張制限（2023年7月時点）

クラウドコンソール操作

1. 対象の仮想マシンを停止します。起動中の場合、RootVolumeの拡張は出来ません
   
   
   
2. 停止済みであることを確認し、対象の仮想マシンを開きます
   
   
   
3. 「ボリューム」アイコンから「●●●● ボリューム操作へ」を開きます
   
   
   
4. リサイズ対象のRootボリュームを開きます
   
   
   
5. 「リサイズ」アイコンを開き、任意のサイズを入力、「リサイズ」ボタンをクリックします
   
   
   
   
   
6. 「はい」をクリックし、リサイズが完了したことを確認します
   
   
   
   
   
7. 対象のRootボリュームがリサイズされていることを確認します
   
   
   

リサイズ出来ない場合

「リサイズ」アイコンがグレーアウトして選択できない場合は、以下の可能性があります

1. 対象Rootボリュームの仮想サーバーが起動中
   
2. 対象Rootボリュームの仮想サーバーが停止直後（数分お待ちください）
   

100GBを超える値を入力した場合はエラーメッセージが表示され、リサイズできません

CentOS での反映

クラウドコンソールからのRootボリュームリサイズは完了しましたが、この状態ではOSで利用できない状態です。
本稿では「growpart」を利用してオンラインで利用可能状態にします

実行するコマンドは以下です
※df コマンドなど確認のための基本コマンドは省略しています

1. yum install -y cloud-utils-growpart
   
2. growpart /dev/sda 1
   
3. xfs_growfs /dev/sda1
   

実際の出力結果

# df -hファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         476M     0  476M    0% /dev
tmpfs            487M     0  487M    0% /dev/shm
tmpfs            487M  1.5M  485M    1% /run
tmpfs            487M     0  487M    0% /sys/fs/cgroup
/dev/sda1         15G  1.8G   14G   12% /
tmpfs             98M     0   98M    0% /run/user/0# yum install -y cloud-utils-growpart～ 長いので省略 ～
# growpart /dev/sda 1
CHANGED: partition=1start=2048 old: size=31455232end=31457280 new: size=209713119end=209715167# xfs_growfs /dev/sda1
meta-data=/dev/sda1              isize=512agcount=4, agsize=982976 blks
         =sectsz=512attr=2, projid32bit=1=crc=1finobt=0spinodes=0
data     =bsize=4096blocks=3931904, imaxpct=25=sunit=0swidth=0 blks
naming   =version 2bsize=4096   ascii-ci=0ftype=1
log      =internal               bsize=4096blocks=2560, version=2=sectsz=512sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096blocks=0, rtextents=0
data blocks changed from 3931904 to 26214139# df -hファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         476M     0  476M    0% /dev
tmpfs            487M     0  487M    0% /dev/shm
tmpfs            487M  1.5M  485M    1% /run
tmpfs            487M     0  487M    0% /sys/fs/cgroup
/dev/sda1        100G  1.8G   99G    2% /
tmpfs             98M     0   98M    0% /run/user/0

すんなり Rootボリュームのリサイズが完了し、100GBになっていることが確認できます。
これでOS上からも利用が可能となります

Windows Server での反映

1. 「ディスクの管理」画面を開き、リサイズした領域が「未割り当て」として表示されている事を確認します
   
   
   
2. 既存領域を右クリック、「ボリュームの拡張」を選択します
   ※「未割り当て領域」を右クリックしても「ボリュームの拡張」メニューが出ません
   
   
   
3. 「ボリュームの拡張ウィザード」が表示されるので、「次へ」をクリックします
   
   
   
4. 「ディスクの選択」が表示されるので、「次へ」をクリックします
   
   
   
5. 「ボリュームの拡張ウィザードの完了」が表示されるので、「完了」をクリックします
   
   
   
6. 正常に拡張されたことを確認します
   
   
   
   

「未割り当て領域」が表示されない場合

「操作」>「最新の情報に更新」を行い、表示されることを確認します

「ディスクの管理」がどこにあるかわからない場合

「ファイル名を指定して実行」 （キーボードの Windows + R）から、「diskmgmt.msc」を入力、「OK」ボタンをクリックして実行します
余談ですが、「compmgmt.msc」を入力、実行することで「コンピューターの管理」を開く事もできます。
※コンピュータの管理からでも「ディスクの管理」画面を操作することが可能です

これで Windows Server 上からも利用が可能となりました。
Windows Server はGUI上で操作が可能なので楽ですね。

まとめ

今後も機能強化に取り組んでいきますので、ご期待ください！
今後の機能強化予定についてはこちら(https://www.idcf.jp/cloud/function.html )
この記事が皆さまの参考となれば幸いです。

こんにちは、藤城（@tafujish）です。
最近、生成AIをはじめAIとそれを動かすGPUの拡がりはすごいですね。
大規模なAIを独自に開発・利用するには、GPUを活用した大規模なITインフラの構築が必要になります。実際、IDCフロンティアのデータセンターを活用した例が続いてます。

www.idcf.jpwww.idcf.jp

IDCフロンティアでは、AIを活用し新サービスや研究を行う企業やアカデミックの方向けに「AI開発推進プログラム」の提供を開始しました。
www.idcf.jp

そこで、今回は「AI開発推進プログラム」にて無償提供しているIDCFクラウドのgpu.7XLP100上で、大規模かつオープンな日本語LLMであるOpenCALMを動かす方法をご紹介したいと思います。

• GPUを搭載したVMを作成
• GPU実行環境を構築
• LLMを実行
• むすび

# apt update
# apt install cuda -y
# reboot

# nvidia-smi
Sat Dec  1 12:01:00 2023       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla P100-PCIE-16GB           On  | 00000000:14:00.0 Off |                    0 |
| N/A   37C    P0              26W / 250W |      0MiB / 16384MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+
                                                                                         
+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

# apt install python3-pip -y
# pip3 install transformers torch torchvision accelerate

import transformers
from transformers import AutoModelForCausalLM, AutoTokenizer, TextStreamer

assert transformers.__version__ >= "4.34.1"

model = AutoModelForCausalLM.from_pretrained("cyberagent/calm2-7b", device_map="auto", torch_dtype="auto")
tokenizer = AutoTokenizer.from_pretrained("cyberagent/calm2-7b")
streamer = TextStreamer(tokenizer, skip_prompt=True, skip_special_tokens=True)

prompt = "AIによって私達の暮らしは、"

token_ids = tokenizer.encode(prompt, return_tensors="pt")
output_ids = model.generate(
    input_ids=token_ids.to(model.device),
    max_new_tokens=100,
    do_sample=True,
    temperature=0.9,
    streamer=streamer,
)

# python3 ./sample.py
pytorch_model.bin.index.json: 100%|█████████████████████████████████| 23.9k/23.9k [00:00<00:00, 113MB/s]
pytorch_model-00001-of-00002.bin: 100%|█████████████████████████████| 9.98G/9.98G [00:46<00:00, 216MB/s]
pytorch_model-00002-of-00002.bin: 100%|█████████████████████████████| 4.04G/4.04G [00:18<00:00, 217MB/s]
Downloading shards: 100%|███████████████████████████████████████████| 2/2 [01:06<00:00, 33.05s/it]
Loading checkpoint shards: 100%|████████████████████████████████████| 2/2 [00:09<00:00,  4.55s/it]
generation_config.json: 100%|███████████████████████████████████████| 132/132 [00:00<00:00, 1.22MB/s]
tokenizer_config.json: 100%|████████████████████████████████████████| 674/674 [00:00<00:00, 6.19MB/s]
tokenizer.json: 100%|███████████████████████████████████████████████| 3.27M/3.27M [00:00<00:00, 3.90MB/s]
special_tokens_map.json: 100%|██████████████████████████████████████| 585/585 [00:00<00:00, 5.18MB/s]
どんどん便利になっていきます。
しかし、便利になる反面、その便利さが問題になっていることをご存知でしょうか？
例えば、私達の生活に欠かせない存在となりつつあるスマートフォンですが、その便利さの裏側で、個人情報の漏洩やハッキング問題、SNSによる未成年への性被害などが多発し、問題視されています。
また、AIは便利だけではなく、多くの危険も孕んでいることを知る必要があります。
AIを搭載したロボットに仕事を奪われる未来が迫っていることはご存知でしょうか
# python3 ./sample.py
Loading checkpoint shards: 100%|████████████████████████████████████|2/2 [00:09<00:00,  4.83s/it]
生活全般が「効率化され」、「便利になって」いますが、その反面多くの危険と不安を抱え込むことになってしまっています。
現在、AIによる自動車、IoT家電、介護ロボット、ロボット、スマートグリッドなど、あらゆる領域でAIは活用されてきていますが、AIが人間に取って代わるのではなく、「人間とAIが共生していく」時代の到来も考えられます。
そして、このような社会において、ますます重要になっていくのが「倫理観」です。AIは人間より賢いと

こんにちは、事業推進本部SE部の山手です。

今回は「Terraform」を利用してIDCFクラウド内に仮想マシンを作成し、同時にその仮想マシンにSSHでアクセスできる環境を構築する方法を紹介します。

目次

• 目次
• Terraformとは
• 実施内容
• 作業手順
  • 1.Terraformのインストール
  • 2.作業用ディレクトリの作成
  • 3.Terraform構成ファイル(以下、構成ファイル)の作成
    • 今回作成した構成ファイルの全体像
    • 今回作成した構成ファイルの詳細説明
  • 4.コードの実行
    • ①構成ファイルを含む作業ディレクトリを初期化する(必須)
    • ②構成ファイルを実行すると何が作成されるのか事前に確認する
    • ③事前確認した内容を実行する
• 終わりに
  • おまけ

Terraformとは

Terraformとは、HashiCorp社が提供しているIaC(Infrastructure as Code)ツールです。

IaCツールとは簡単にいうと、インフラ環境をコードとして管理するツールです。
そのため、コマンドを実行するだけで誰もが同じインフラ環境を構築することができるようになります。

www.terraform.io

UIで操作して仮想マシンを作成することは簡単ですが、複数作成する場合は手順漏れや人為的ミスが起こりがちです。 そのようなミスの発生を、Terraformを使って防ぎましょう。

実施内容

◆仮想マシンの作成
◇グローバルIPアドレスの取得
◇ポートフォワーディング設定
◇ファイアウォールの設定
（◇は、作成した仮想マシンにSSHでアクセスするために、仮想ルーターに対して設定を行っています。）

作業手順

それでは、実際に作成してみましょう。
※今回はRocky Linux9.2で作業しています。

1.Terraformのインストール

# インストール[ayamate@terraform]$ sudo yum -y install terraform
# 確認[ayamate@terraform]$ terraform version

2.作業用ディレクトリの作成

Terraformは、カレントディレクトリ内の構成ファイル(拡張子は「.tf」)をもとにインフラ環境を操作します。
そのため、作業用のディレクトリを作成してその中で操作する必要があります。ディレクトリの作成に命名規則はありません。
※今回はディレクトリ名「terraform」で作成しました。

#作業用ディレクトリの作成[ayamate@terraform]$ mkdir terraform
#作業用ディレクトリに移動[ayamate@terraform]$ cd terraform

3.Terraform構成ファイル(以下、構成ファイル)の作成

作業用のディレクトリの中に構成ファイルを作成する必要があります。構成ファイルの作成に命名規則はありませんが、拡張子は「.tf」である必要があります。 また、構成ファイルを複数に分けることも可能です。
※今回はファイル名「main.tf」にまとめて作成しました。

#作業用ディレクトリ配下に構成ファイルを作成[ayamate@terraform]$ vi main.tf

今回作成した構成ファイルの全体像

#変数の宣言variable myip {default = "***,***,***,***"}variable cloudstack_api_url {default = "WWWWWWWWWWWWWWWWWWWWWWWW"}variable cloudstack_api_key {default = "XXXXXXXXXXXXXXXXXXXXXXXX"}variable cloudstack_secret_key {default = "YYYYYYYYYYYYYYYYYYYYY"}variable network_id {default = "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"}#プロバイダーの指定terraform{required_providers{cloudstack = {source = "cloudstack/cloudstack"version = "0.4.0"}}}#IDCFクラウドAPIキーの参照先provider"cloudstack"{api_url = "${var.cloudstack_api_url}"api_key = "${var.cloudstack_api_key}"secret_key = "${var.cloudstack_secret_key}"}#作成するVMの詳細設定resource"cloudstack_instance""vm"{name = "XXXXXXXXXXXXXXXXX"
  service_offering= "light.S1"network_id = "${var.network_id}"template = "CentOS 7.9 64-bit"zone = "volt"keypair = "YYYYYYYYYYYYYYYYYYYY"}#取得するグローバルIPアドレスの設定resource"cloudstack_ipaddress""public_ipaddress"{network_id = "${var.network_id}"zone = "volt"}#フォワーディング設定resource"cloudstack_port_forward""pf_ssh"{ip_address_id = "${cloudstack_ipaddress.public_ipaddress.id}"forward{protocol = "tcp"private_port = 22public_port = 22virtual_machine_id = "${cloudstack_instance.vm.id}"}}#ファイアウォール設定resource"cloudstack_firewall""myip"{ip_address_id = "${cloudstack_ipaddress.public_ipaddress.id}"rule{cidr_list = ["${var.myip}/32"]protocol = "tcp"ports = ["22"]}
}

#実行output"public_ipaddress"{value = "${cloudstack_ipaddress.public_ipaddress.ip_address}"}

この構成ファイルを実行してIDCFクラウド上に仮想マシンを作成することができます。

今回作成した構成ファイルの詳細説明

【変数宣言】

variable myip {default = "***,***,***,***"}variable cloudstack_api_url {default = "WWWWWWWWWWWWWWWWWWWWWWWW"}variable cloudstack_api_key {default = "XXXXXXXXXXXXXXXXXXXXXXXX"}variable cloudstack_secret_key {default = "YYYYYYYYYYYYYYYYYYYYY"}variable network_id {default = "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"}

・myip
　⇒クラウド環境への通信を許可するIPアドレス

・cloudstack_api_key_url
　⇒IDCFクラウドAPIのURL
　(IDCFクラウドコンソールの「アカウント設定」の「API」の「リージョンとエンドポイント」の「エンドポイント」の値)
　https://console.idcfcloud.com/user/apikey
　※リージョンごとにエンドポイントが違うのでご注意ください

・cloudstack_api_key
　⇒IDCFクラウドAPIのAPI Key
　(同じ画面の「User Key」の「API Key」の値)

・cloudstack_secret_key
　⇒IDCFクラウドAPIのSecret Key
　(同じ画面の「Secret Key」の値)

・network_id
　⇒仮想マシン作成先のネットワークID
　(「コンピュート」の「ネットワーク」の「作成先ネットワーク名」の「ネットワークID」の値)
　https://console.jp-east-3.idcfcloud.com/compute/network/
　※上記URLは東日本リージョン3の画面なので、他のリージョンの場合は画面上で対象リージョンをお選びください

【プロバイダーの指定】

#プロバイダーの指定terraform{required_providers{cloudstack = {source = "cloudstack/cloudstack"version = "0.4.0"}}}#IDCFクラウドAPIキーの参照先provider"cloudstack"{api_url = "${var.cloudstack_api_url}"api_key = "${var.cloudstack_api_key}"secret_key = "${var.cloudstack_secret_key}"}

・provider
　⇒IDCFクラウドでは、クラウド基盤のソフトウェアとしてCloudStackを利用しているため Cloud Stack のTerraformプロバイダーを利用します。

【仮想マシン設定】

#作成するVMの詳細設定resource"cloudstack_instance""vm"{name = "XXXXXXXXXXXXXXX"
  service_offering= "light.S1"network_id = "${var.network_id}"template = "CentOS 7.9 64-bit"zone = "volt"keypair = "YYYYYYYYYYYYYYYYY"}

・name
　⇒作成するVMの名前

・service_offering
　⇒仮想マシンタイプの指定

・network_id
　⇒仮想マシン作成先のネットワークID
　※マシン作成のためにネットワークIDは必須です。

・template
　⇒利用するテンプレート

・zone
　⇒作成先ゾーンの指定

・keypair
　⇒公開鍵認証に利用する公開鍵の名前
　※事前にSSH Keyの取得が必要です。

【グローバルIPアドレス設定】

#取得するグローバルIPアドレスの設定resource"cloudstack_ipaddress""public_ipaddress"{network_id = "${var.network_id}"zone = "volt"}

・zone
　⇒作成先ゾーンの指定

【ポートフォワーディング設定】
※仮想ルーターに対して、設定を行っています。

#フォワーディング設定resource"cloudstack_port_forward""pf_ssh"{ip_address_id = "${cloudstack_ipaddress.public_ipaddress.id}"forward{protocol = "tcp"private_port = 22public_port = 22virtual_machine_id = "${cloudstack_instance.vm.id}"}}

・private_port
　⇒宛先プライベートポートの指定

・public_port
　⇒受信元パブリックポートの指定

【ファイアウォール設定】
※仮想ルーターに対して、設定を行っています。

#ファイアウォール設定resource"cloudstack_firewall""myip"{ip_address_id = "${cloudstack_ipaddress.public_ipaddress.id}"rule{cidr_list = ["${var.myip}/32"]protocol = "tcp"ports = ["22"]}
}

・cidr_list
　⇒アクセス元のIPアドレス

・ports
　⇒特定IPアドレスからのアクセスを許可するポート番号

【取得したグローバルIPアドレスの表示】

#IPアドレスの表示output"public_ipaddress"{value = "${cloudstack_ipaddress.public_ipaddress.ip_address}"}

4.コードの実行

構成ファイルを作成したら、3つのTerraformコマンドを実行します。

①構成ファイルを含む作業ディレクトリを初期化する(必須)

# 初期化作業[ayamate@terraform]$ terraform init

Initializing the backend...

Initializing provider plugins...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

(Terraform has been successfully initialized!と表示され初期化が完了したことがわかります。)

②構成ファイルを実行すると何が作成されるのか事前に確認する

# 事前の確認[ayamate@terraform]$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # cloudstack_firewall.myip will be created
  + resource "cloudstack_firewall""myip"{
      + id            = (known after apply)
      + ip_address_id = (known after apply)
      + managed       = false
      + parallelism   = 2

      + rule {
          + cidr_list = [
              + "***.***.***.***/32",
            ]
          + icmp_code = (known after apply)
          + icmp_type = (known after apply)
          + ports     = [
              + "22",
            ]
          + protocol  = "tcp"
          + uuids     = (known after apply)
        }
    }

  # cloudstack_instance.vm will be created
  + resource "cloudstack_instance""vm"{
      + display_name     = (known after apply)
      + expunge          = false
      + group            = (known after apply)
      + id               = (known after apply)
      + ip_address       = (known after apply)
      + keypair          = "XXXXXXXXXX"
      + name             = "terraform-test"
      + network_id       = "YYYYYYYYYY"
      + project          = (known after apply)
      + root_disk_size   = (known after apply)
      + service_offering = "light.S1"
      + start_vm         = true
      + tags             = (known after apply)
      + template         = "CentOS 7.9 64-bit"
      + zone             = "volt"}# cloudstack_ipaddress.public_ipaddress will be created
  + resource "cloudstack_ipaddress""public_ipaddress"{
      + id            = (known after apply)
      + ip_address    = (known after apply)
      + is_portable   = false
      + is_source_nat = (known after apply)
      + network_id    = "XXXXXXXXXX"
      + project       = (known after apply)
      + tags          = (known after apply)
      + zone          = "volt"}# cloudstack_port_forward.pf_ssh will be created
  + resource "cloudstack_port_forward""pf_ssh"{
      + id            = (known after apply)
      + ip_address_id = (known after apply)
      + managed       = false

      + forward {
          + private_port       = 22
          + protocol           = "tcp"
          + public_port        = 22
          + uuid               = (known after apply)
          + virtual_machine_id = (known after apply)
        }
    }

Plan: 4 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + public_ipaddress = (known after apply)

qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

(Plan: 4 to add, 0 to change, 0 to destroy.と表示され、四つの項目(上から、ファイアウォール設定、仮想マシン作成、パブリックIPアドレス取得、ポートフォワーディング設定)が実行されることを事前に確認できます。)

③事前確認した内容を実行する

# 実行[ayamate@terraform]$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # cloudstack_firewall.myip will be created
  + resource "cloudstack_firewall""myip"{
      + id            = (known after apply)
      + ip_address_id = (known after apply)
      + managed       = false
      + parallelism   = 2

      + rule {
          + cidr_list = [
              + "***.***.***.***/32",
            ]
          + icmp_code = (known after apply)
          + icmp_type = (known after apply)
          + ports     = [
              + "22",
            ]
          + protocol  = "tcp"
          + uuids     = (known after apply)
        }
    }

  # cloudstack_instance.vm will be created
  + resource "cloudstack_instance""vm"{
      + display_name     = (known after apply)
      + expunge          = false
      + group            = (known after apply)
      + id               = (known after apply)
      + ip_address       = (known after apply)
      + keypair          = "XXXXXXXXXX"
      + name             = "terraform-test"
      + network_id       = "YYYYYYYYYY"
      + project          = (known after apply)
      + root_disk_size   = (known after apply)
      + service_offering = "light.S1"
      + start_vm         = true
      + tags             = (known after apply)
      + template         = "CentOS 7.9 64-bit"
      + zone             = "volt"}# cloudstack_ipaddress.public_ipaddress will be created
  + resource "cloudstack_ipaddress""public_ipaddress"{
      + id            = (known after apply)
      + ip_address    = (known after apply)
      + is_portable   = false
      + is_source_nat = (known after apply)
      + network_id    = "XXXXXXXXXX"
      + project       = (known after apply)
      + tags          = (known after apply)
      + zone          = "volt"}# cloudstack_port_forward.pf_ssh will be created
  + resource "cloudstack_port_forward""pf_ssh"{
      + id            = (known after apply)
      + ip_address_id = (known after apply)
      + managed       = false

      + forward {
          + private_port       = 22
          + protocol           = "tcp"
          + public_port        = 22
          + uuid               = (known after apply)
          + virtual_machine_id = (known after apply)
        }
    }

Plan: 4 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + public_ipaddress = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

cloudstack_ipaddress.public_ipaddress: Creating...
cloudstack_instance.vm: Creating...
cloudstack_ipaddress.public_ipaddress: Creation complete after 1s [id=b10ec419-ca98-4f13-9e30-d7f6dce7328d]
cloudstack_firewall.myip: Creating...
cloudstack_instance.vm: Still creating... [10s elapsed]
cloudstack_firewall.myip: Still creating... [10s elapsed]
cloudstack_instance.vm: Still creating... [20s elapsed]
cloudstack_firewall.myip: Still creating... [20s elapsed]
cloudstack_firewall.myip: Creation complete after 23s [id=b10ec419-ca98-4f13-9e30-d7f6dce7328d]
cloudstack_instance.vm: Still creating... [30s elapsed]
cloudstack_instance.vm: Still creating... [40s elapsed]
cloudstack_instance.vm: Still creating... [50s elapsed]
cloudstack_instance.vm: Creation complete after 58s [id=83c120ab-b6ae-4f3b-9f21-bfe363517f13]
cloudstack_port_forward.pf_ssh: Creating...
cloudstack_port_forward.pf_ssh: Creation complete after 8s [id=b10ec419-ca98-4f13-9e30-d7f6dce7328d]

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

Outputs:

public_ipaddress = "***.***.***.***"

(Do you want to perform these actions?と表示され、実際に作成するか尋ねられます。
yesと回答すると、Apply complete! Resources:4 added, 0 changed, 0 destroyedと表示され作成が完了したことを確認できます。)

終わりに

AWSの環境をTerraformで構築する情報は多いですが、cloudstackのTerraformプロバイダーを利用した仮想マシンの作成については情報が少なく、プロバイダーを指定するコードの作成に時間がかかりました。
(AWSはhashicorpの公式プロバイダーのため、プロバイダーの指定の仕方が異なります。)
繰り返し利用できるコードですので、皆さまもぜひIaCツールで仮想マシンを作成してみてください！

おまけ

#プロバイダー指定に失敗した際のエラー文例
Error: Failed to query available provider packages

Error: Invalid provider local name

というようなエラー文が出た際はプロバイダーの指定方法を見直してみてください。

▼参考にさせていただいた資料
■2016年時点で同様の検証を行った記事
https://qiita.com/akito1986/items/df84e1015d46f4be7b48qiita.com

■プロバイダー(CloudStack)のバージョンの確認先
https://registry.terraform.io/providers/cloudstack/cloudstack/latestregistry.terraform.io

こんにちは。プラットフォーム開発部の阿部です。
IDCFクラウド のYAMAHA vRXを使ってIDCFクラウドローカルとAWS間をVPN接続する方法を紹介します。

• 背景と目的
• 前提条件
• 構築の流れ
• 構築手順
  • 1.ゲートウェイ構築
    • 1-1.IDCFクラウド　仮想マシン作成(vRX)
    • 1-2.IDCFクラウド　仮想マシン作成(サーバ)
    • 1-3.vRX基本設定
    • 1-4.パブリックIPアドレス作成
    • 1-5.SSH接続
    • 1-6.vRXオプション設定
    • 1-7.サーバのゲートウェイ設定
  • 2.VRRP構成
    • 2-1.IDCFクラウド　仮想マシン作成(vRX)
    • 2-2.vRX②設定
    • 2-3.3つ目のIPアドレスの取得
    • 2-4.VRRP IPアドレス設定
    • 2-5.シャットダウントリガー設定
    • 2-6.NATするIPアドレスの変更設定
  • 3.AWSとのVPN接続
    • 3-1.AWS カスタマーゲートウェイ(CGW)の作成
    • 3-2.AWS 仮想プライベートゲートウェイ(VPGW)の作成
    • 3-3.AWS 作成した仮想プライベートゲートウェイ(VPGW)をVPCに適用
    • 3-4.AWS ルートテーブルの追加
    • 3-5.AWS Site-to-Site VPN 接続の作成
    • 3-6.AWS 設定のダウンロード
    • 3-7.vRX トンネル設定の適用
    • 3-8.IDCFクラウドのFW許可設定
• まとめ

背景と目的

IDCFクラウドローカルのマシンとSSL-VPNを用いて、インターネット経由で外部クラウド環境等にアクセスを行うような構成が必要になる場合もあると思います。
そのような時、ネットワーク機器を別途購入して環境構築することもできると思いますが、IDCFクラウドで提供しているサービスを利用して構成することができるので、一例としてAWSとVPN接続の構築をこの回で実施したいと思います。

前提条件

・IDCFクラウドにて提供しているテンプレートイメージ「YAMAHA vRX(19.01.09)」を利用します。
・マシンのスペック(CPU、メモリ)を変更できますが、YAMAHAのシステム要件に沿ったものとします。
www.faq.idcf.jp

・IDCFクラウドのvRXライセンスは基本機能のみとなり、VPNなどのオプションはYAMAHAよりライセンスの別途調達が必要となります。
www.faq.idcf.jp

・本記事に記載のあるIPアドレスなどの固有情報はテスト用のため、実際に構築する環境の各サービスの制限に合わせて設定を行ってください。

構築の流れ

本記事ではVPN接続までを以下3段階に分けて記載します。
・1.ゲートウェイ構築
　　IDCFクラウドでのYAMAHA vRX構築方法について記載します。
・2.VRRP環境構築
　　前項で記載したYAMAHA vRXゲートウェイを2台で冗長化する方法について記載します。
・3.AWSとのVPN接続
　　IDCFクラウドでのYAMAHA vRXとAWSをVPN接続する方法について記載します。

構築手順

1.ゲートウェイ構築

〇構成図(vRXシングル構成)

〇IPアドレス
この項目では以下とします。

1-1.IDCFクラウド　仮想マシン作成(vRX)

①.IDCFクラウドコンソールにログインして仮想マシン作成します。
「IDCFクラウドコンソール」→「コンピュート」→「仮想マシン」で「仮想マシン作成」をクリックします。

②.仮想マシンスペックの選択を実施 vRXの仮想マシンを作成します。

この記事では以下とします。

1-2.IDCFクラウド　仮想マシン作成(サーバ)

接続テスト用の仮想マシンを作成します。
この記事では以下とします。

1-3.vRX基本設定

vRXに接続するための基本的な設定を実施します。

①.コンソール接続する
vRX初期設定のためvRXの仮想マシンにコンソール接続します。
「IDCFクラウドコンソール」→「コンピュート」→「仮想マシン」にて対象の仮想マシンのリンクをクリック、 対象の仮想マシンのウィンドウから「コンソール」→「コンソールにアクセスする」をクリックします。

②.vRXにログイン
ログインユーザが設定されていないため「Enter」打鍵で進みます。

③.管理ユーザに移行
初期の管理ユーザパスワードは空欄のためエンターで進みます。

④.任意のログインユーザ名とログインパスワード設定

⑤.SSH サーバーホスト鍵を生成

⑥.SSH サーバー機能を ON に設定

⑦.IPアドレス設定
設定するIPアドレスはIDCFクラウドコンソールで指定したIPアドレスを指定します。

⑧.管理者パスワードを更新

⑨.設定の保存

1-4.パブリックIPアドレス作成

各マシンにネットワーク経由でSSHログインするためのパブリックIPアドレスを取得します。
この記事では以下とします。

パブリックIPアドレスの作成方法およびNAT設定については以下をご参照ください。
www.idcf.jp

接続対象マシンへのアクセス制御設定については以下をご参照ください。
www.idcf.jp

1-5.SSH接続

この記事ではサーバ②を踏み台としてSSH接続する構成とています。
ローカル端末からサーバ②のパブリックIPアドレスに接続後、各マシンにSSH接続をしています。

IDCFクラウドの仮想マシンへのSSH接続方法については以下をご参照ください。
参考：IDCFクラウド めちゃ楽ガイド

1-6.vRXオプション設定

①.SSH認証鍵の登録
ログイン時の鍵認証に利用する鍵を作成します。
登録する秘密鍵は事前にローカル端末にて作成します。

②.時刻同期設定
時刻同期します。

IDCFクラウドにて利用化な時刻同期先は以下をご参照ください。
www.faq.idcf.jp

vRXの仕様上、定期的な時刻同期がされないため、スケジュール登録して時刻同期します。

③.DNS設定
DNSの登録を行います。ここではゲートウェイを指定します。

④.NAT設定
NATの設定を行います。ローカルNWから外部に出るときのIPアドレスのNAT設定を追加します。

1-7.サーバのゲートウェイ設定

サーバ①においてvRX①LAN2のIPアドレスをデフォルトゲートウェイに指定します。

ここまででサーバ①はvRXを中継して外部へのアクセスが可能になります。

2.VRRP構成

〇構成図(VRRP構成)

〇IPアドレス
この記事では以下とします。

2-1.IDCFクラウド　仮想マシン作成(vRX)

1-1の手順をご参照いただき仮想マシン作成を実施します。
この記事では以下とします。

2-2.vRX②設定

1-3,1-6の手順をご参照いただきvRX設定を実施します。

2-3.3つ目のIPアドレスの取得

VRRPを構成するために3つ目のIPアドレスを取得します。

IDCFクラウドコンソールより「ネットワーク」を選択後、3つ目のIPアドレスを払い出すネットワークの「ネットワーク名」のリンクを選択する。

ポップアップウィンドウにて「IPアドレス一覧」を選択すると、対象のネットワーク内で利用されているもしくはシステム上予約されているIPアドレスが表示されます。

IPアドレス一覧から種別が「仮想マシン用IP範囲外」となっているIPアドレス範囲を確認して、範囲内から利用可能なIPアドレスを一つ確認してください。
ここでは払い出す3つ目のIPアドレスを以下とします。

補足
「仮想マシン用IP範囲外」のIPアドレスは仮想マシンに割りあてをされないIPアドレスとなります。
利用されているかどうかがシステム上管理をされないため、対象範囲から利用したIPアドレスは重複しないように管理をお願いします。

2-4.VRRP IPアドレス設定

vRX①のローカルIPアドレスをVRRPのアドレスに、空きとなったvRX①のローカルIPアドレスに前項で取得したIPアドレス設定します。

2-5.シャットダウントリガー設定

VRRPはプライオリティ設定でmaster側を優先にしているためインターフェースや片側のマシンに問題があった場合、backup側へ自動で切り替えを実施します。

2-6.NATするIPアドレスの変更設定

NATするouterのIPアドレスをVRRPのIPアドレスに変更します。

ここまででVRRP設定が完了となります。

3.AWSとのVPN接続

〇構成図(VPN接続構成)

〇IPアドレス
この記事では以下とします。

〇本項目の前提
　・AWS側のVPCやsubnetはすでに作成されている前提で解説します。
　・AWSのSite to site VPN（インターネット網での環境A←→環境Bの接続）を利用してVPN接続します。
　・AWSのVPNトンネルは2つが自動作成されます。
　・BGPでの動的ルーティングではなく静的ルーティングで設定を行います。
　・AWSのUIについては本掲載作成時点の内容で作成しており、変更される場合があります。

3-1.AWS カスタマーゲートウェイ(CGW)の作成

ーーーー本項はAWS側の操作となります。ーーー

AWSの画面にて[VPC]>[カスタマーゲートウェイ]>[カスタマーゲートウェイの作成]を選択します。

[カスタマーゲートウェイの作成]の画面で、下記の項目を入力し、[カスタマーゲートウェイの作成]ボタンをクリックします。

3-2.AWS 仮想プライベートゲートウェイ(VPGW)の作成

AWSの画面にて[VPC]>[仮想プライベートゲートウェイ]>[仮想プライベートゲートウェイの作成]をクリックします。

[仮想プライベートゲートウェイの作成]の画面で、下記の項目を入力し、[仮想プライベートゲートウェイの作成]ボタンをクリックします。

3-3.AWS 作成した仮想プライベートゲートウェイ(VPGW)をVPCに適用

[仮想プライベートゲートウェイの作成]の画面で前項で作成した「仮想プライベートゲートウェイ」を選択後、[アクション]>[VPCにアタッチ]をクリックします。

[VPCへアタッチ]の画面で適用対象のVPCを選択後、[VPCへアタッチ]ボタンをクリックします。

3-4.AWS ルートテーブルの追加

VPCからIDCFクラウドのローカル環境への静的ルートの追加をします。
AWSの画面にて[VPC]>[ルートテーブル]をクリック、対象のルートテーブルを選択後、[アクション]＞[ルートを編集]をクリックします。

[ルートを編集]の画面で以下のルートを追加後[設定を保存]ボタンをクリックします。

3-5.AWS Site-to-Site VPN 接続の作成

カスタマーゲートウェイと仮想プライベートゲートウェイを紐づけします。

AWSの画面にて[VPC]>[Site-to-Site VPN 接続]>[VPN接続を作成する]をクリックします。

[VPN接続を作成する]の画面で以下を設定します。

ゲートウェイの選択

ルーティングオプションの選択

ネットワークCIDRの設定
ここではデフォルトのままとします。

設定が問題なければ[VPN接続を作成する]ボタンをクリックします。

3-6.AWS 設定のダウンロード

vRXに適用するトンネル設定のダウンロードを行います。
AWSの画面にて[VPC]>[Site-to-Site VPN 接続]をクリック、対象のVPN接続を選択後、[設定をダウンロードする]をクリックします。

[設定をダウンロードする]の画面で以下を選択して[ダウンロード]ボタンをクリックします。

ローカル端末にvRXに適用するトンネル情報が記載されたコンフィグファイルがダウンロードされます。

3-7.vRX トンネル設定の適用

ーーーーここはvRX側での操作となります。ーーー

3-6でダウンロードしたファイルを参照して必要に応じて適用します。
以下サンプルコンフィグとなります。環境に合わせて変更してください。

3-8.IDCFクラウドのFW許可設定

ーーーーここはIDCFクラウドコンソールでの操作となります。ーーー
IDCFクラウドコンソールにて「vRX①」に割り当てているパブリックIPアドレスのファイアウォール設定でVPN接続に必要なポートの許可設定を実施します。
ファイアウォール設定方法は以下をご参照ください。
www.idcf.jp

許可設定対象は以下です。

ここまででIDCFクラウドのマシンとAWSのインスタンス間の疎通が取れるようになります。

まとめ

以上のように、IDCFクラウドで提供されている機能や資源を利用して、VPN環境を用意することがができます。
ぜひ、本記事をご参考にしてVPN環境の構築をお試していたければと存じます。

▼参考にさせていただいた資料▼
YAMAHA作成のvRX導入するためのユーザガイド
www.rtpro.yamaha.co.jp

YAMAHA作成のvRXのコマンドリファレンス
www.rtpro.yamaha.co.jp

ーーー
Amazon Web Services、AWSは、Amazon.com, Inc. またはその関連会社の商標です。