概要: 自分なりに考えた結果をまとめてみる
本日、自分が担当する家事を一通り終わらせてから、 PM 7:30 〜 PM:10:30 まで居眠りした結果、 AM 12:40 現在、まったくもって寝れないので、 とりえずしばらく前から考えていた、
- Immutable Infrastructure や
- Contianer base deploymenet における
- Stateful data の保存方法の指針
について、自分の考えを整理するついでにまとめてみます。
※ ちなみに僕は Web 実務経験がないです。 プログラミング経験は 7 年ぐらいあるけど
Immutable な インフラやコンテナでは、すべてのデータは揮発すると考える
ぶっちゃけ前に僕が書いた記事、
- [[個人用途の VPS の管理を Docker ベースにした /post/66636256465]]
という記事に書かれた作業をやっていた時に気がついたのですが、 基本的に Container base deployment は immutable で、 Container の中で変更したデータ、というのは大体消えます。
で、これに似たような状態のデータストアってなんだろう、 って考えて思い出したのが、主に、キャッシュ等の用途に使われる、
- memcached
- Redis
等の、オンメモリがベースのデータストアなんですよね。
Redis はまあ設定によってはデータ内容をストレージに保存できますが、 memcached はインスタンスが落ちたら中身は全部消え去るので、 その辺りの特徴としては、Immutable Infrastructure なり、 Immutable Container なりの、データ保存の現状と同じではないのか、 と思うんですよね。
で、僕としては、この Immutable な環境での、
- すべてのデータはインスタンスが消えれば揮発する
というのは、考え方のポイントでは無いかと思います。
揮発するデータをどうやって復元するか
で、次。
Immutable infrastructure なり、Container base deployment では、 基本的にインフラやコンテナに変更を加える際は、 インフラやコンテナのビルドスクリプト、 例えば Docker なら Dockerfile で、コンテナ作り直して、 それを既存のコンテナと入れ替える、という事をします。
で、その入れ替えの際、Immutable infrastructure では、 基本的に既存のインフラやコンテナには一切手を加えず、 新しいインフラやコンテナを一から作り直して、 その新しいインフラなりコンテナなりを、 Zero downtime で、既存のインフラコンテナと切り替える、 というコトをすると思います。
んで、先のセクションで、Immutable Infrastructure や、 あるいは Container base deployment では、 Stateful なデータは全部揮発する、と考えるのがポイントと言いましたが、 じゃあデータが揮発するなら、どうやって新しいコンテナ等を作る際に、それを復元したら良いかと考えると、これは、
- データの記録のログを全部コンテナ or インフラの外部に取る
- 新規コンテナ or インフラの作成の際、そのログを使ってデータを復元する
というような感じでやればいいのかなーと僕は思います。
でもこれ、全部自前のサーバでやっちゃうと、 Redis に重要なデータ全部ぶっ込んで、 一回もクラスタをダウンさせずに運用するという、 結構デンジャラスというかリスキーというか、 そういうドキドキわくわく絶望サーバ運営ランドになると思うので、 その辺りのログ保存等については、
- Amazon S3
- Riak CS Enterprise
等の、外部サービス使うといいんじゃないかと思います。
最後に、僕の考えたコンテナ構成
で、上記を踏まえて、僕は、 具体的にこんなコンテナ構成を考えてみました。 ちなみにこれは僕が作りたいと考えている、 2ch 型掲示板みたいなのを想定してます。
- データ保存の流れ 1. データの保存は、すべて
fluentd経由で行う
fluentdでは、書き込みログをRiakと S3 に投げるRiakはクラスタを組み、fault tolerance を実現しておく- S3 のログは、ある程度の周期で集約し、古いログに関しては Amazon Glacier にぶっこむ
- S3 上には、コンテナ再作成用に、すべてのログを集約したログファイルを保存しておく
- データストアコンテナの新規 / 再作成 1. S3 から今までの書き込みログを取得しておく
- Dockerfile や Packer のテンプレート等で、そのログを import するようにする
- 作り直したコンテナを Riak Cluster に join させる
- あとは Riak が勝手に分散処理してくれる
まあとりあえず以上な感じでやれば、 stateful なデータが揮発しても大丈夫なのかなーと思います。
ただまあどっちにしろ stateful なデータは、 いつかどこかに保存しなければならない情報なので、 その辺り自分自身の Server side Operation を信用しない僕としては、 Amazon S3 とかの実績のある企業に任せるしかないかなーと思ってます。 すくなくとも自前でやるよりかはマシだと思うしね。僕のスキルの場合。
で、あとまあ僕の考えたやり方というのは、大体、
- 揮発するデータストアと、揮発しないログストアに同時にデータ投げる
- 揮発するデータストアを復元する際には、揮発しなりログストアからログ引っ張ってくる
- あとは古いデータストアコンテナを新しいデータストアコンテナに入れ替える
- Riak みたいな分散が全自動なデータストアだと、色々らくっぽい
という感じで、基本的な考え方としては、 他のデータストアでも適用できるのはないか lang:ja と思ってます。 まあ実戦経験ないんで微妙に卓上の空論かもですけどね(>_<;)
というわけで記事を書き始めてから 45 分ぐらい経ったんですが、 今だに眠くなりません……が、 とりあえず書きたいコトはかけたのでよしとします。
という事でもう寝ます。おやすみなさ〜い。
#FIXME
