カラクリサイクル

『輝かしい青春』なんて失かった人の雑記

immutable Infrastructure / Container base deploymentにおける stateful dataの保存方法

概要: 自分なりに考えた結果をまとめてみる


本日、自分が担当する家事を一通り終わらせてから、 PM 7:30 〜 PM:10:30まで居眠りした結果、 AM 12:40現在、まったくもって寝れないので、 とりえずしばらく前から考えていた、

  1. Immutable Infrastructureや
  2. Contianer base deploymenetにおける
  3. Stateful dataの保存方法の指針

について、自分の考えを整理するついでにまとめてみます。

※ ちなみに僕はWeb実務経験がないです。 プログラミング経験は7年ぐらいあるけど

Immutable な インフラやコンテナでは、すべてのデータは揮発すると考える

ぶっちゃけ前に僕が書いた記事、

という記事に書かれた作業をやっていた時に気がついたのですが、 基本的にContainer base deploymentはimmutableで、 Containerの中で変更したデータ、というのは大体消えます。

で、これに似たような状態のデータストアってなんだろう、 って考えて思い出したのが、主に、キャッシュ等の用途に使われる、

  1. memcached
  2. 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なデータは全部揮発する、と考えるのがポイントと言いましたが、 じゃあデータが揮発するなら、どうやって新しいコンテナ等を作る際に、それを復元したら良いかと考えると、これは、

  1. データの記録のログを全部コンテナ or インフラの外部に取る
  2. 新規コンテナ or インフラの作成の際、そのログを使ってデータを復元する

というような感じでやればいいのかなーと僕は思います。

でもこれ、全部自前のサーバでやっちゃうと、 Redisに重要なデータ全部ぶっ込んで、 一回もクラスタをダウンさせずに運用するという、 結構デンジャラスというかリスキーというか、 そういうドキドキわくわく絶望サーバ運営ランドになると思うので、 その辺りのログ保存等については、

  • Amazon S3
  • Riak CS Enterprise

等の、外部サービス使うといいんじゃないかと思います。

最後に、僕の考えたコンテナ構成

で、上記を踏まえて、僕は、 具体的にこんなコンテナ構成を考えてみました。 ちなみにこれは僕が作りたいと考えている、 2ch型掲示板みたいなのを想定してます。


  • データ保存の流れ
    1. データの保存は、すべてfluentd経由で行う
    2. fluentdでは、書き込みログをRiakとS3に投げる
    3. Riakはクラスタを組み、fault toleranceを実現しておく
    4. S3のログは、ある程度の周期で集約し、古いログに関してはAmazon Glacierにぶっこむ
    5. S3上には、コンテナ再作成用に、すべてのログを集約したログファイルを保存しておく
  • データストアコンテナの新規 / 再作成
    1. S3から今までの書き込みログを取得しておく
    2. DockerfileやPackerのテンプレート等で、そのログをimportするようにする
    3. 作り直したコンテナをRiak Clusterにjoinさせる
    4. あとはRiakが勝手に分散処理してくれる

まあとりあえず以上な感じでやれば、 statefulなデータが揮発しても大丈夫なのかなーと思います。

ただまあどっちにしろstatefulなデータは、 いつかどこかに保存しなければならない情報なので、 その辺り自分自身のServer side Operationを信用しない僕としては、 Amazon S3とかの実績のある企業に任せるしかないかなーと思ってます。 すくなくとも自前でやるよりかはマシだと思うしね。僕のスキルの場合。

で、あとまあ僕の考えたやり方というのは、大体、

  1. 揮発するデータストアと、揮発しないログストアに同時にデータ投げる
  2. 揮発するデータストアを復元する際には、揮発しなりログストアからログ引っ張ってくる
  3. あとは古いデータストアコンテナを新しいデータストアコンテナに入れ替える
  4. Riakみたいな分散が全自動なデータストアだと、色々らくっぽい

という感じで、基本的な考え方としては、 他のデータストアでも適用できるのはないか lang:jaと思ってます。 まあ実戦経験ないんで微妙に卓上の空論かもですけどね(>_<;)


というわけで記事を書き始めてから45分ぐらい経ったんですが、 今だに眠くなりません……が、 とりあえず書きたいコトはかけたのでよしとします。

という事でもう寝ます。おやすみなさ〜い。