自宅サーバ群でクラスタ構築をしました
Twitchで配信をしながら、勉強しつつ１０時間かけてクラスタ構築とクラスタへの移行を行いました。
クラスタを構築したのは良いもののデータベースを実行してるメインサーバが吹き飛んだので、やってからこの記事を書くまで時間が経過しました。
サーバが吹き飛んだことに関するIQ3まとめについては下記の投稿を見てください。
サーバーがカーネルパニック起こしたと思ったらハードウェアごと吹き飛んだ件
なぜクラスタを構築したのか？
大きく２つの理由があります。
１つ目は学習目的です。クラスタに関して興味深くQiitaやZennその他様々な記事を目にしていましたが、いままで一度も構築したことがありませんでした。そこでやってみようと考えました。好奇心的なところが強いです。そもそもとして、私が自宅にサーバを持っている理由が学習目的なので、こういう感じで結構色々気軽にやってたりします。
２つ目は複数台管理が面倒くさかったです。クラスタ構築して運用できれば、個別にSSHでいちいちつないで細かく設定する必要がなくなるので、かなり管理の手間が減ると思いました。実際、楽になりました。初期に色々設定するという面ではかなり手間はありますが、そこさえ乗り越えれば楽です。
上記の２つの理由からクラスタ構築を自宅サーバ群で行いました。
自宅サーバ群につ いて
サーバ群なんて言っていますが、今回のクラスタ構築では３台のみで考えました。今後追加することも一応考慮しています。
１台目
データベースやゲームサーバー、その他諸々一番色々やっているサーバ。スペックもメモリも一番ある。
ストレージは、SSDにOS、HDD２枚にそれぞれバックアップと本番の運用データが乗ってます。
OSはUbuntu Server 20.04、もともとはCentOSで運用していましたがCentOS 8でなくなるということでDebian系に乗り換えました。Ubuntuを選択した理由は、割と安定しながらも、バージョンを比較的新しいのを使ってくれるからです。後は最近のOSSとかがUbuntuで動かすことを想定して作ってることが多かったりするなんて理由もあります。あまり細かいことは考えてません。
２台目及び３台目
Raspberry Pi 3 Model B+です。
どちらもTeam GroupのSDカード32GBを指してあります。
OSはUbuntu Server 20.04です。
基本的にデータを保持せず、サービスをDockerなどで動かしているだけです。このウェブサイトのウェブサーバーもラズパイで動作しています。データはデータベースやNASなどに放り込 んであります。
後日、外部HDDをつなげてNAS化する計画がありますが、それはおいおいの話なので、ストレージは無いものとして扱います。
３台目以降
現在はありませんが、今後追加する可能性があるという事を考慮して構築しました。まだ扱いを考えていますが、クラウドのクラスタを自宅サーバのクラスタと混ぜてしまってもいいかなと考えているので、そういった可能性も考慮しつつ作ります。
オーケストレーションに何を使うのか
クラスタ構築で重要なオーケストレーションシステムをどのように選んだのかという話です。
最も有名なオーケストレーションシステムの１つとして、k8s（Kubernetes）があると思います。Googleが設計したやつで、デファクトスタンダードの立ち位置にあるオーケストレーションシステムです。
k8sは技術トレンドですし、扱えたらなんかカッケー！とは思いますが、ここは現実的な事を考えましょう。まずk8sはプロダクション環境で使われることが多く、そこで使うことを想定した作りとなっています。実際Googleさんとか色々な企業は数千ノードをk8sとかで扱っているとか...
しかし私は一般家庭、プロダクション 環境ではないのです。もちろん数千ノードなんて扱うことは有りません。現在稼働させてるサーバーをオンプレ・クラウド合わせてもいいとこ１０数個です。まず２０ノードを超えることは有りません。ということはそこまで高性能である必要も無ければ、プロダクション環境に対応できるだけのスケールアウト可能なシステムである必要もありません。
k8sが無いとすると次に挙がってくるオーケストレーションシステムといえば、Docker Swarmです。これはDocker-ce自体に統合されているものなので、追加のインストールなどは必要なく、Docker engineが使えれば利用可能です。
補足ですが、「Docker Swarm 終了」や「Docker Swarm サポート終了」といったサジェストが出てきて、その旨の記述をするブログが散見されますが、終わったのは、Docker-Swarm-Mode-As-A-Serviceです。Docker Swarmが完全に削除されたわけではなく、開発が終了したわけではないです。
これ以外に利用されるオーケストレーションとしてGKEやECS、OpenShift、Rancherなどなど色々ありますが、他のは情報少なかったり、クラウドでやること想定されてたりなので、考えないこととします。後は単純に導入の手間とコストに見合わないです。
Kubernetes vs Docker Swarm
少なくとも私が自宅サーバ群でクラスタ構築するにあたり、どちらが良いのか。実際に検証したわけではありませんが、ある記事を見つけたのでそちらの情報を参照します。
[和訳]Docker SwarmとKubernetesの比較 #docker - クリエーションライン株式会社
ここでは技術コンサルタントのJeff NickoloffとDockerが契約して、パフォーマンス評価をした結果の和訳が掲載されています。
中身はここでは解説しないので、簡単に呼んで頂くとして、重要な２つのパフォーマンス評価項目とその結果に注目します。
評価項目は「コンテナの起動にかかる時間」と「高負荷状態での応答性」です。後者のような状態になることは想定してないし、プロダクションでもないので最悪time outしてもいいかなぐらいの気持ちではいますが、良いに越したことは有りません。
結果だけ書くと、コンテナの起動にかかる時間はDocker Swarmの方が５倍早く、クラスターの負荷率がほぼ100％であったとき、Kubernetesはクラスターの形成状態が10％～100％に到達するまで、Docker Swarmの98倍の時間がかかっています。
できることの幅は間違いなくk8sの方が良いです。ただしk8sは純粋に複雑なんです。ちょっとしたことをやるためにも色々やる必要があります。大規模なサービスを厳格に動かす場合、おそらくk8sは向いているでしょうが、自宅でちょっとクラスタを動かすぐらいであれば、複雑でパフォーマンスが出ないk8sよりもDocker Swarmの方が良いという結論になりました。
これは私の結論なので、自分で作る場合はぜひ自分で選択してほしいですが、少なくとも少ないサーバー台数で、１人でシンプルに物事を進めたいのであ れば、Docker Swarmの方が向いていると思います。
WebUI
さて一人で管理していくとなると、WebUIがあったほうが楽ですし、やりやすいです。全部CUIでやれという意見も理解はしますが、人間なのでGUIに甘えたいです。
ここに関しては割とすぐに決まりました。というかだいぶ前からクラスタ構築のための構想は頭で練っていて、もともとこれでいいでしょって感じで決めていました。
選ばれたのはPortainerでした。
Container Management | Kubernetes GUI | Docker Swarm GUI | Portainer
Dockerの WebUIで一番有名なのが、Portainerだと思いますね。なぜこれを選んだか話もしたいんですが、いうほど掘れる話題無いです。軽量で簡単に動かせて手間かからないのが、Portainerぐらいで他のWebUI系はパッとしなかった。
クラスタ構築してどうなったのか
まだ結果は出ていません。現状大きな問題はなく順調に動いており、快適といえば快適という感じになっています。その一方、クラスタである必要はないと思うこともあります。今後の課題です。
また、時間が足りなかったりメンテナンスにそこそこな時間を割かなくてはいけないという点から、一部コンテナはStackとしてデプロイできていないです。さらには新たな問題点も見つけているので、今後の課題が積み重なっています。色々勉強しながら、ベストプラクティスを模索していきたいと思います。
今後、ちょこちょことこういう問題あった！解決した！といった系の投稿を小出ししていこうと思います。
大きなアウトプットしようとすると、時間ばかりが経過して何日も投稿しない日が続くのでね...