さくらのクラウドファーストインプレッション

## 概要

遅ればせながら、このたびはじめてさくらのクラウドをさわりました。
これまでは AWS やニフクラくらいしか使っていなかったので、結構戸惑いました。
一通り作ったりマニュアルを読んだりした限りでの、第一印象を残しておこうと思います。
間違っているところや理解違いもあるかもしれませんが、今後きちんと把握していきたいですね。

## サンプル

[こちら](https://github.com/shztki/sakura)に上げてみましたが、Terraformで一通りのリソースを作成できます。
[ドキュメント](https://sacloud.github.io/terraform-provider-sakuracloud/)もちゃんとありますし、スムーズに利用することができました。
これは非常に好印象ですね。
いまさら、インフラ構築を手作業でやるようなことは避けたいですし。

## メモ
* 分散ファイアウォールが無いのが辛い
「パケットフィルタ」というのがありますが、ステートレスなためちょっと扱いにくいですし、セキュリティも微妙です。
許可したい通信以外すべて Deny したいと思ったら、内→外通信時の戻りのために大量のポート開放が必要ですし、その際の送信元をしぼれるわけもなく。
AWS での NetworkACL のように、サブネット間の通信制御とかだったらいいとは思うのですが。
VMware の NSX Firewall とか AWS の SecurityGroup のように、ステートフルな FW がほしいところです。
今さら、サーバ内で iptables 設定とか、したくないなぁ。。。
「ルーター＋スイッチ」でインターネット回線と CIDR を確保し、VPCルータを置いて、その配下のスイッチに接続したプライベートなサーバに NAT させるような構成にすれば、VPCルータでファイアウォール機能を使うことはできるようです。
ただこの NW にする時点で 1万超え/月の費用がかかり、ファイアウォールを使いたいためだけで選定するものではないですね。
IPエイリアスも 8個までしか持てませんし。
あとは VPCルータの代わりに自分で vSRX等何かしらのファイアウォールを運用するかですが、冗長構成にするべきだし、費用面や構築・運用面でもいろいろとハードルがありそう。
せっかくサーバ/ディスク単体だと安いし、使い勝手もよいクラウドなのに、惜しい感じがしてなりません。
とにかく、分散ファイアウォールがほしい。。。

* Terraformでのパケットフィルタ設定のループの回し方
[こちら](https://sacloud.github.io/terraform-provider-sakuracloud/configuration/resources/packet_filter_rule/)でコメントアウトされている count を使う方法だと、 `order` がうまく機能しないのか、順番が無茶苦茶になりました。
以下なら一応きちんと意図した順番になりました。

```
resource "sakuracloud_packet_filter" "myfilter" {
  name        = var.filter["name"]
  description = var.filter["memo"]

  dynamic "expressions" {
    for_each = var.protocol
    content {
      protocol    = var.protocol[expressions.key]
      source_nw   = var.source_nw[expressions.key]
      source_port = var.source_port[expressions.key]
      dest_port   = var.dest_port[expressions.key]
      allow       = var.allow[expressions.key]
    }
  }
}
```

* [特殊タグ](https://manual.sakura.ad.jp/cloud/server/special-tags.html)が面白い。
`@group=a` 等の指定だけで簡単にホストを別にできるのはとても楽でよいし、無料なのもすごいですね。
ニフクラのサーバーセパレートは有償でしたし。
AWS は AZ別で作るだけですむのでもっといいですけど。
`@auto-reboot` で CloudWatch の Auto Recovery 的なことが手軽にできるのも面白いです。

* 専有ホスト(Windows)プランにしても、Windowsのライセンス持ち込みはできないのかな？
SQLとか一部だけかなとは思いますが。

* RHEL ってないんですね。ちょっとびっくりしました。
専有ホストで契約したら、ライセンス持ち込みできるのかな？
できるとしたら自分で ISOイメージ上げて、それでサーバ作成、なのかな。

* [自動バックアップ](https://manual.sakura.ad.jp/cloud/appliance/autobackup/)について、最大 1TBまでとあるが、コンパネでは 2TBと表示される。
どっちだろう？ まぁコンパネが正しいのかな。。。
どちらにしろ、作れるディスクサイズすべてに対応できないのは、うーん。。。
アカウントあたり 5個しか設定できないし(1設定で対象にできるのは 1ディスクのみ)、実行時間も指定できないしで、ちょっと使いづらいところですね。

* 全体的に、やはりどこもストレージには難儀している感じですね。
AWS が「16 TB のボリューム全体の EBS スナップショットにかかる時間が、1 TB のボリューム全体のスナップショットを作成する場合の時間を超えない設計になっています」とか言ってるのは、ホントすごいことなんだなぁ。。。

* WindowsServer作成時、いちいち初期設定(ライセンス同意、言語設定、パスワード設定)をリモートコンソールで実施する必要があるのは面倒。
完了済みのイメージではダメなのかな？(パスワードや IPアドレスだけ作成時に指定するような)
そもそもなぜ Windows ではスクリプト(userdataみたいなもの)が使えないのだろう。

* Sophos を使えるみたいだけど、クラスタは組めないらしい。

* ロードバランサについて、いまどき DSR型でサーバ側に設定必要なのはちょっとなぁと思った。
昔はよく使っていたんですけど。。。
GSLB はいいです。エンハンスドロードバランサも。でもプライベートには対応していない。
やはりここも、分散ロードバランサがあった方がいいのかな。。。

* エンハンスドロードバランサのアイドル[タイムアウト時間](https://manual.sakura.ad.jp/cloud/appliance/enhanced-lb/#enhanced-lb-timeout)はどれだろう。
10~600のやつかな。短い気もする。
AWS の ALB でも標準 60 秒で短くて問題になった[ケース](https://qiita.com/nagaakihoshi/items/f7326978221ee053d208)があった。こっちは 3,600 にできたけど。

* GSLB について、port は health_check 内のパラメータ。
[こちら](https://sacloud.github.io/terraform-provider-sakuracloud/configuration/resources/gslb/)のコメントアウトしてる場所がちがった。

* スクリプトについて、[コメント](https://manual.sakura.ad.jp/cloud/startup-script/about.html#id8)の記述で初回のみ実行や毎回実行になったりするのが面白い。

* スイッチが AWS でいう Subnet かなと思っていたので、CIDR を設定する箇所が無いことがすごい不思議な感覚。。。
名前を付けるだけ。

* ブリッジでさくっと別リージョンや他サービス(VPSや専用サーバ)と L2接続ができるのはすごい。
石狩-東京間はやっぱりちょっと RTT が大きくなりますね。
 
```
[root@dr001 ~]# ping 192.168.201.10
PING 192.168.201.10 (192.168.201.10) 56(84) bytes of data.
64 bytes from 192.168.201.10: icmp_seq=1 ttl=64 time=35.2 ms
64 bytes from 192.168.201.10: icmp_seq=2 ttl=64 time=16.9 ms
64 bytes from 192.168.201.10: icmp_seq=3 ttl=64 time=16.9 ms
64 bytes from 192.168.201.10: icmp_seq=4 ttl=64 time=16.9 ms
^C
--- 192.168.201.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 16.905/21.513/35.230/7.919 ms
[root@dr001 ~]# ping 192.168.201.101
PING 192.168.201.101 (192.168.201.101) 56(84) bytes of data.
64 bytes from 192.168.201.101: icmp_seq=1 ttl=64 time=0.891 ms
64 bytes from 192.168.201.101: icmp_seq=2 ttl=64 time=0.409 ms
64 bytes from 192.168.201.101: icmp_seq=3 ttl=64 time=0.439 ms
64 bytes from 192.168.201.101: icmp_seq=4 ttl=64 time=0.500 ms
^C
--- 192.168.201.101 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.409/0.559/0.891/0.196 ms
```

* スイッチに接続できる「ブリッジ/ハイブリッド/ローカルルータ」はいずれかの 1つのみ。

* プライベートIP のみのサーバを作るときも、IP設定をコンパネ上で指定できるので、作成後すぐに疎通可能な点は便利。
ディスク修正機能いいですね。ニフクラにはない機能ですけど、あちらは userdata 使えばいいだけではあります。

* VPCルータで L2TPVPNする場合は、[こちら](https://knowledge.sakura.ad.jp/15081/)参照。
インターネット向けも含め、全通信が VPCルータ経由になる。

* エンハンスドLB を試したら、エラーになって作成できなかった。。。
理由が表示されないので、まったくわからなかったが、ソーリーサーバの指定をやめると作成できた。
そこでようやく気づいたが、外部の IPアドレスはダメなんですね、GSLBとちがって。。。
気が付いたら当たり前のことでしたけど、わかりにくい。エラー理由を言って欲しかった。。。

* [データベース](https://manual.sakura.ad.jp/cloud/appliance/database/index.html)については、RDS とまではいかない感じ。
「小規模なウェブアプリケーションや開発環境などの用途に最適です。」とあるくらいだし、あまり充実はしていないのかも。
PostgreSQL11 か MariaDB10.3 しか選択肢もないし、本番用途では厳しそう。
リードレプリカはあるものの、冗長化やフェイルオーバーもないし。
WebUI を有効にしたら phpMyAdmin や pgAdmin が使えるのはおもしろいけど。

* NFS もシングル構成のサーバができあがるようなもので、管理は楽だが冗長とかフェイルオーバーはなし。
AWS の EFS とは比べられない。

* 「マップ」画面が操作できてびっくりした。
作成済みのリソースで構成図を作ってくれる機能ですが、表示されているスイッチやサーバをマウスのドラッグ&ドロップで移動可能で、きれいに整理できることに驚きました。

## まとめ

非常に使いやすかったので、これからもっとちゃんと勉強していきたいと思います。