がるの健忘録 このページをアンテナに追加 RSSフィード

2017-03-13

[][]異字体

大本ネタはこちら。

http://moriyoshi.hatenablog.com/entry/2017/03/13/011005

ここで「異体字セレクタ」ってのをはじめて知って、ちょろっと調べものをしたので、備忘録的に。

UnicodeっつかUTF-8で「1文字づつ」に分割するごにょごにょを書きたいかもなぁ、とか、ちょろっと妄想をしていたので。


とりあえず。

(二点しんにょう U+8FBB + VS18) ⇔「辻??」(一点しんにょう U+8FBB + VS17)

……ふお?

U+8FBB はわかるんだが、 + VS18、って、なにかしらん?

が、startライン。


http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/?rt=nocnt

見ると、「E9 82 8A F3 A0 84 80」とか「E9 82 8A F3 A0 84 81」とか。


念の為に、UTF-8エンコーディング方法を確認。

https://ja.wikipedia.org/wiki/UTF-8

………ぶも?

5バイト長とか6バイト長とかある???

一端より道して調べもの。…いやもしあるんなら。MySQLのutf8mb4が、些か、怖いやもしれぬので。


https://ja.wikipedia.org/wiki/Unicode%E4%B8%80%E8%A6%A7%E8%A1%A8

http://www.unicode.org/roadmaps/


ふむ。第16面でも「U+F0000 〜 U+10FFFF」なのねん。

これだと十分に4バイトで入る。…5バイト長とか6バイト長は「将来に向けての布石」なのかしらん?

とりあえず「当面の厄介」は消えたぽいので、「5バイト長とか6バイト長」の調査は一端ここで打ち切り


もどして…とりあえず、ビット列に分解して、有効な値を取り出してみる。


E9 82 8A F3 A0 84 80

1110 1001 1000 0010 1000 1010 1111 0011 1010 0000 1000 0100 1000 0000


E9 82 8A F3 A0 84 81

1110 1001 1000 0010 1000 1010 1111 0011 1010 0000 1000 0100 1000 0001


使う子だけ、はじき出す…とりあえず先頭は多分3バイトのはず。

1110 yyyy 10yx xxxx 10xx xxxx

1110 1001 1000 0010 1000 1010 1111 0011 1010 0000 1000 0100 1000 0000

1110 1001 1000 0010 1000 1010 1111 0011 1010 0000 1000 0100 1000 0001


どっちも

1001000010001010

908A


うん確かに「邊」の字だ。

てことは手前3バイトは文字なんだ…後ろの4バイトを解析してみませう。

先頭が11110なんで、UTF-8的には「4バイト文字」のはず。


1111 0yyy 10yy xxxx 10xx xxxx 10xx xxxx

1111 0011 1010 0000 1000 0100 1000 0000

1111 0011 1010 0000 1000 0100 1000 0001


011100000000100000000

011100000000100000001


E0100

E0101


一覧を見てみる…

https://ja.wikipedia.org/wiki/Unicode%E4%B8%80%E8%A6%A7_E0000-E0FFF

「VS17」とか「VS18」とか。


あぁ!!

単純に、ここらへん(おそらく、E0100〜E01E0F)までは「異字体(IVS:Ideographic Variation Sequence)だよ!!」って取決めなのか!!

うん、腑に落ちた。


ってことは「1文字を切り出す」時に、もし後ろにこの子がいたら「前の字とセットで」持っておいてあげる必要があるんだなぁ。

PHPの実装とかどうなってるんだろ?

まぁその辺はまた後日、気になったら調べてみませうw

2017-01-19

[][]「言語の仕組み」とかを学ぶのによい書籍群

うちの生徒さんから

最近プログラムの言語(言語の仕組み)やアセンブラとかに興味が向いて来てるんですけどオススメの書籍とかってあったりしますか?

という質問が来たので、ちょいとDMだと長くなりそうなのもあって、Blog私信を書いてみます(笑


んと…まず「言語の仕組み」って意味では「コーディングを支える技術」がとてもお勧め。

「さまざまな言語を縦櫛で貫く」あたりのこの書き方は、本当に今でもしびれるほど素晴らしいと思ってるざんす。


また、最近出てきた「まつもとゆきひろ 言語のしくみ」も、これは「言語を開発する」って観点から書かれてるので、ちょっとだけ横道かもしれないけど、面白いざます。


「言語を作る」の延長線としての「コンパイラ」に興味があったら、とりあえずは

スモールコンパイラ の制作で学ぶ プログラムのしくみ

スモールコンパイラ の制作で学ぶ プログラムのしくみ

が、ライトだと思う。

この後は「レッドドラゴン」とか、撲殺できる書籍に向かう方面になる(笑


この辺を踏まえた上で…アセンブラの本、になると「ど真ん中」にお勧めなのは少ないので、ちょっと脇道にいきながら。


初めに読んでおくとよいなぁと思うのが「コンピュータアーキテクチャエッセンス」。

アセンブラを理解するための基礎体力」が見につくので、強くお勧め。

ハード周りに興味が出たら

に寄り道するのも、ありw


この後は色々散らかるんだけど…アセンブラの書き方そのものであれば、手元にある書籍的には「熱血!アセンブラ入門」が割とお勧めかなぁ。

熱血!アセンブラ入門

熱血!アセンブラ入門

鈍器だけど(笑)、基本的な「アセンブラでの記述の仕方」が色々と書いてあるので、よいと思う。

で、これを読んだうえで。興味があったら、おいちゃんが(某人物とタッグ組んで)仕様を作った「terakoya_cpu( http://www.m-fr.net/tane/study/learn_c/terakoya_cpu_20070722.pdf )」を見てみると、面白いかも。

シンプルなセットだけど、一応これだけで「一通りあらゆる事が出来る」ように設計をしてあるので。

元々「学習用途を想定して作った」ものではあるんだけど、それだけに「本当に最低限」しかない言語仕様なので、シンプルに色々とまとまってるつもり。


Binary Hacks ―ハッカー秘伝のテクニック100選

Binary Hacks ―ハッカー秘伝のテクニック100選

あたりも、一度は目を通しておくと面白い。


ちょっと横道だけど

なんてのも「バイナリレイヤーを知る」って意味ではやはり面白い。


この辺が、今の所すっと浮かぶ「おいちゃん手持ちの中からのお勧めの書籍」かなぁ。

2016-09-01

[]IDEについて、とか

発端はここのあたり。

https://twitter.com/ndxbn/status/771350294940692481

@gallu 多分だけど、がる師には「肌に合わない」と思うんですよ。まぁそもそもIDEがあんまり好きくなさそうかなぁと。 composerとかnpmとかで管理し、上書き保存にhookしてphp-cs-fixerした後に開発環境と同期してブラウザを更新、とかするの好きくないでしょ?


うんまぁ割と正解なんだけどw

自分でも興味深かったので「現時点での印象値」を書いてみようかなぁ、と。


端的には

https://twitter.com/gallu/status/771350997587197952

@ndxbn 「理念」としては理解も納得もできるし受け入れられるんだけど「実装と実態」みると腰が引ける、ってのはあるなぁ(苦笑

ってあたりなんだけど、かみ砕いて。


まず、一番許容可能なのは「上書き保存にhookしてphp-cs-fixerした後に開発環境と同期してブラウザを更新」あたり。

まず「上書き保存にhookしてphp-cs-fixer」は、おおむね許容可能。「上書き保存にhookして」は100%許容可能で、あとはphp-cs-fixer。

単純に「おいちゃんのデフォが、PHP CS Fixerの標準とちょっと違う」ので。「設定を変えるのか」「おいちゃんを変えるのか」でちょいと悩むくらいw

いやこれが「現場の仕事」なら躊躇なくPHP CS Fixerにも合わせますが、個人のコードだと「俺のモンだしなぁ」ってのもあり。とりあえずおいちゃんは蛇なのだ。ラクダぢゃないのだwww


多分「蛇をラクダにする」のは、個人プロダクトとしては「絶対に嫌」なんだけどw*1

括弧のつけ方だのインデントの切り方だのは…どうすっかなぁ? レベル。

まぁ必要になってから考えましょw


composerとnpmについては「理屈はわかるが根底と実装がお好まない」の感じ、ってのが端的な見解。


どちらも「パッケージ管理システム」って前提で。

いや実際「インストールとupdateと一覧の作成と削除、依存関係の管理」が出来るのは、色々と便利だなぁとは思うのですが(実際、「雑に」サーバを作るときは、おいちゃんもyumとか使うし)。

少しド直球に剛速球を投げると「そもそも、依存関係の管理が必要な時点で、設計の一歩目の失敗があるよねぇ」ってのは、ぶっちゃけ思います。


疎結合どこいった?


まぁ言っても詮無い話ではあるのですがね。

ただ「マイナーどころかメンテナンスバージョンまで細かく指定しないと動かない」とか見ると、些か疑問符が付くところではございます。


その辺を乗り越えて考えてみると…次にどうしても気になるのが、composerなりnpmの実装。

もうちょっと正確には「インストール対象をちゃんと精査してるか? 出来るか?」問題。


「複雑な依存関係を自動で解決したい」ってニーズがある以上「誰かが作ってくれた依存リスト、に依存する」のはある意味正しいのですが。

そこに「悪意が入り込んできた」場合の精査って、誰がするんでしょ? ってあたり。

懸念じゃなくて、実際に、npmにしてもcomposerにしても起きてるわけだし。


もちろん「気づいてみんな大騒ぎして自浄作用が働く」ってのは可能性としてあるし実際働いている(と思う)んだけど。

ただ「誰かが騒ぐまで気づかない」ってのはどうなんだろう? ってのと、「そこに至るまでにどれくらいの被害が出るんだろう?」と。


その辺を考えると。

「composerないしnpmを使わないとインストールできない」ものであればやむなし、なんだけど。

「使わなくてもさほど大きなコストがかからずにインストールできる」んなら、ちゃんと依存関係を自力でひも解いた上で「自力でやる」ほうが、何かあった時に「アンテナにひっかけやすい」んじゃないかなぁ、とか思ってみたりするわけなのでございます。


ん…おいちゃん的には「glibc」の話が、これに少し近い感覚があるのかもしれない。

真っ当にLinux触ってる人間(≒カーネルコンパイルしたりしている系統の人種)であれば。「glibc ライブラリの脆弱性」とか見るととりあえず逆毛が立つと思うのですが(苦笑

「なんとなく手順通りyumでインストールして手順書通りの作業をしている」だけの人だと、「glibc? 聞いたことないなぁ」ってなりそうな気がしているっていうか実際何度か耳にして正直耳疑ったw


その辺を考えると。

いや一つの回答としての「composerとnpmを、ちゃんと精査した上で使う」ってのはより正しいと思うんだけど。

「そこまでコスト払ってらんないしなぁ」ってなると「じゃぁ一端使うのは見送るか」ってなりがちなんだなぁ、と。


なので。

composerとnpmについては「もうちょっと見通しよくならんかなぁ」とかほんのり思ったりするのですが…まぁ使うとしたら「がっつり調べてから使う」から、結構な調査コストかけるんだろうなぁ(苦笑


ちなみにIDEの話が全然出てないのでちょろっとだけ書くとw


すげぇ単純には

・なくても書けるけどあったほうが書くのがはかどる可能性が高いよねぇ


を前提に

・重たいとか落ちるとか不安定とかは論外なのでそーゆーIDEならいらん

・おいちゃんは「リモートベース」なので、リモートファイルがいじれない子はちょっと使えない

・入力補助は「慣れ」の問題なので不問

・「たくさんの機能」は、うれしい可能性もあるけど邪魔な可能性もある:せめて「機能を切れる(削除できる)」と、重さが軽くなるのでベター


って感じ。

ただ根底に「そもそも、コード書く時間そのものって、システム開発全体からするとそんなに大ボリュームでもなくない?」ってのが少しあるので。

そんなに、IDEについて大きくこだわったりはしないかなぁ。


現場からは以上です。

*1:人間って「生き死にに関わらない些細でどうでもいい」事象に対しては、割と「決定的かつ致命的なこだわりがある」ものざますw

2016-02-10

[][]論理削除とサロゲートキー

いや端的には「どっちも原則的にはいらん」っていう立ち位置なのですが。

その辺も含めて、一旦「現時点での」おいちゃんのスタンスを、メモ程度に。


論理削除

最近見ていると割と「いらん!」な方向に向いている記事が多いのであんまり気にならないっちゃぁ気にならないのですが。

おいちゃんの現在のスタンスは「原則、物理削除」。

ここからいくつかお話が散らかるのですが…

まず第一に考えるべきなのは


・その削除は、削除ですか? stateの変動ですか?


という疑問。

この辺りは

「DELETE_FLAG を付ける前に確認したいこと。( http://qiita.com/Jxck_/items/156d0a231c6968f2a474 )あたりが大変に興味深いのでご一読のほどを。


結論として。

基本的には、おいちゃんは「異なるstateなら異なるテーブルに」なので、DELETE+INSERTで「データが入ってるテーブルを切り替える」ほうが多いのですが。

「諸々の制約や予算コストの類の消耗」が受け入れられる範囲における「論理削除」であれば、状況によっては(例:削除後もkeyの重複を避けたい)、可能性として考慮しうる選択肢だと思います。

一方で「とりあえず全てのテーブルにdelete_flag」というのは、何一つ受け入れられない主張だなぁ、と、おいちゃんは感じるわけなのですね。


あと、stateの話でもう一つ「虫唾が走る」のが「1テーブルに複数のstateカラムがある」設計。

例えば1stateが2つの状態のスイッチ(いわゆるbooleanな値)だとしても。stateのカラムが6つあれば、実に32パターンのstateが存在しうる状態になるのですよ?

そんなもん、誰がテストしてられっかい(笑


上述の矜持類似で「データの削除は非推奨( http://www.infoq.com/jp/news/2009/09/Do-Not-Delete-Data )」なんてのもあります。こちらも一読推奨。

ここで「単純にinsert時の入力ミスまでロギング的に情報を残すのかね?」という疑問がないではないのですが、まぁ「どこまでがミスによる削除で、どこからがstateを残すべき状態の積み重ねなのか」を議論して議論のテーブルが混乱した挙句にマシンガンを打ち込むくらいなら、一律「削除しねぇ」って選択肢も、まぁ、なくもないのかなぁ、と。


ただ一応、上述に反論を申し述べますと。

おいちゃんのバトルエリアの一つであるソシャゲとかの案件ですと、まず構成がMySQLなので「器用なパーティショニングとか出来ねぇ!」ってのがありまして。

次に「ギリギリまでチューニングしたい」っていう割と切実な状況があるので。

結果的に「いらん(コールド)データを残せる余地なんざあらしませんがな」状態になることも多いので、その場合、あんまり選択の余地はありませぬ。


対運用(より正確には対クレーム)用には、別途、(テキストが望ましいけどまぁ別に切り出すんならDBでも)ログを作っておきませう。


ってなわけで、おいちゃんは「物理削除」が基本になる事が多いです。


サロゲートキー

もうちょっとかしましい感じかなぁ、と。

ネットでみても、現時点で結構「どっちも」な論点があちこち。


まず初めに見ておきたいのが、こちら。

「サロゲートキー vs 複合キー」という間違った対立( http://osa.hatenablog.com/entry/2014/03/19/180330 )。

上述にあるとおり、比較軸が

・自然キー vs 代替キー(おいちゃんは人工キーっていうけど)

・単一キー vs 複合キー

になります(「主キー vs 代理キー」に起因する言い争いは、おいちゃんの観測範囲内だとあんまりないので、一旦省略)。


おいちゃんの基本スタンスは「自然キー(ナチュラルキー)万歳。複合キーもありありで」一派。


まず「単一キー」な状態で「何故に人工キー(サロゲートキー)」をふらにゃならんのか。

"特に問題がない限り"自然キーを素直に使うのが一番素直です。

この辺、奥野さんのスタンスと一緒( http://nippondanji.blogspot.jp/2013/12/blog-post_4.html )。

ここでポイント"特に問題ない限り"。


サロゲートキーを持ち上げる記事の幾つかを見ると、割と典型的なのが

・商品IDとか、年度によって指し示す商品が変わるんですものkeyになんて怖くて出来ません!!

って類の主張。

一方で「それ、そもそも設計ミス」ってツッコミにはなるんだけど、「設計ミスは仕様なので設計ミスではないからこの設計で"正しく"動くように」とかいう上意下達下克上禁止があったりするので、そーゆー時は「自然キーだと特に問題が……あります orz」という状態なので、やむを得ないと思う。

「こういう要求があるから、よい」ではなくて「こういう要求があるから、やむを得ない」。


近しいので興味深かったのが「なぜ私はID派なのか( http://d.hatena.ne.jp/arn/20060903/p2 )」。

「二週間後に社員コード体系(数値→英数+桁数アップ)が変わるんで対応よろしく」とか。

これどう考えても「コード設計が致命的に破綻している」んだけど、現実問題として存在しているんだからしゃぁない。

もちろん「レベル(地位)を上げて物理(圧力とかパワハラとか)で殴る」って政治的解決法も存在しなくはないんだけど、「技術的に」解決させるのであれば「てめぇらのふったコードとかとても信用なんて出来ねぇからこっちで人工キーふって安全に運用するぜ!!」ってなるのもむべなるかな。

まぁ「ご愁傷様です」ってレベルですな。


あとは、ソシャゲなんかですと「IDはint! 文字列とかアリエナイ!」っていう価値観が一定数存在して、かつそれなりに合理的でもあったりするので。

そこで「既存のデータの候補キーがすべてstring」だったりしますと「じゃぁ別途、人工キーをば」って話にならなくもない。

まぁ「いやそもそものデータの候補キー(の1つ)をint型にしろやごるぁ」で片付くことも多いのですが(おいちゃんはこっち)。


「ORマッパーの都合としての人工キー」と、それに伴う「すべてのDBに`id`ってカラムを追加」については…そもおいちゃん、ORマッパー自体にあまり過度なメリットを感じていないので微妙ではあるのですが、基本的にはあんまりお好まないの感じ。

なので「ORマッパーの制限があるから」で「サロゲートキーに」って論法は、あんまりお好まないかなぁ。

「フレームワークの都合で以下略」って状態なら止む無く受け入れない事もないけど、あんまり「是」とは言えないなぁ、という感じ。


次に「複合キーの混雑をさけるための人工キー」については。

弱めに反対だけど、さほど強固に反対でもないかなぁ、程度。

基本的には「ちゃんとSQL書けばいいじゃない」ってなるんだけど。それはおいちゃんの複合キーがせいぜい2カラム程度であることが多かったり、っていう側の事情もあるし。

(やっぱり好まない論点だけど)「ORマッパー的に面倒」ってのもあるし。

その辺を前提に「複合キーが関連するところは、ちゃんとユニーク制約なりぶち込んだ上で、別途サロゲートキーを用意、普段はそっちをよく使う」については、おいちゃんが仕切ってるところだとあんまりよい顔はしないんだろうけど、そこまで「駄目! ゼッタイ!」ってほど強固に反対するものでもないかなぁ、と。


なので、おいちゃんは「自然キー、複合キーありあり」が前提な一派一門に所属しております。


結論として。

もちろん「適材適所」ってのは大前提なんだけど、さりとて「高度の柔軟性を維持しつつ臨機応変に」なんていう虹色な発言は「何も考えてないのと同義だよねぇ」「行き当たりばったりとなにが違うのん?」ってお話になるので。


そんなあたりの理由から、なんとなく「現在のスタンスとか基本指針とか」を書いておきたかったので、メモ。

2015-07-02

[][]サーバ系ツールに関する雑感

開発環境とか本番環境とかデプロイとか「環境の各諸々のバージョンアップ」とかに関する雑感です。

「Jenkinsとchefとデプロイツールに関する雑感」と読み替えてもらっても、そんなに変化はない感じ。

いつも以上に「主観バリバリ」なんで、適当に加減しながら読んでくださいませませ。

想定はLAMP。PはPHPなので、そんな感じで。


さて。

開発環境なんだけど、 http://d.hatena.ne.jp/gallu/20120725/p1 にも書いたとおり、基本的には「開発マシン1台用意して、全員でよってたかって使う」のが好み。

言い方を変えると「個人のPCで各人がvagrantとか使って開発環境作って」ってのが嫌い。

「個人のVirtualが嫌い」な理由は簡単で「簡単に環境差異が発生しうるから」。

平気でroot権限で「合意の取れていないブツをインストールして」、その後出てくるのが「ステージングで動かない → "自分の環境では動いてます (`・ω・´)キリッ"のコンボ」なので。

過去に見てきた限り「禁止してもとまらない」ので、おいちゃん的には割とここは「ガチガチ」でいきたい。


Jenkins

「CIツールとしてのJenkins」については「あんまり存在価値がわからんけど、別にあるならあるで」程度。

コンパイル系言語ならいざしらず。PHPで、見聞きしている範囲で「Jenkinsでやりたいこと」って「git フックでいいぢゃん」って内容ばかりで。

だとすると本質的には「なくてもいい道具は使わない」がおいちゃんの流儀なので、いらにゃい。

ただ、Jenkinsの中を見ていると結構「しゅっ」とした作りなので。「すでにあるから使いたい」とか「視認性的に便利だから使いたい」とかで「使用に肯定的な意見が多い」ようであれば、かたくなに「使うな!!」ってほどの何かはないので、使ってもいいんじゃないかなぁ、と。


Chef

Chefは…正直、まったく「ピン」とこない(苦笑

「Chefなら冪等性が保障される」って話はわりと多々、耳に目にするのですが、正直「レシピ次第」としか。

あと、書き方によっては「意図しないdaemonのupdate」とか「未テストな状態のdaemonのupdate」とか、いろいろ考えちゃうと正直、いまひとつ。

「tar ballを使いたい」っておいちゃんの好みにもわりと合致しないし。結局の所「コードでの管理」なので、事前のコード設計とかちゃんとやらないと「DRYと対極にあるような状況」とかが平気で出てくるので、結局「散らかる → 作り直す」の繰り返しで、手間かかるだけなんじゃねぇかなぁ? って感じがひしひしと。

個人的には、特にクラウドを使ってる場合は「Immutable Infrastructure」って発想がお好みかなぁ。

いろいろあると思うのですが。おいちゃんの想定している運用は…多分、 http://www.publickey1.jp/blog/14/immutable_infrastructure_1.html にある、 http://www.publickey1.jp/blog/14/imm04.jpg の絵がとても近いような気がするのですが。

ようは、ELBをうまくつかいつつ「新しいインスタンスつくったら古いインスタンスは削除すればいいよね」な感じで、大変にクラウドちっくな方法(笑

具体例は以下を参照してくんなまっしょ。


ちなみに「fabric」なるツールを聞いたのですが…まだ斜めに飛ばし読みしかしていないのですが、なんとなく「好みのにおいがした!!!」(笑

気をつけないと乱用しそうなので丁寧に使い倒したいなぁと思うのですが(笑)、使うんならこーゆーシンプルなもののほうがお好みでやんす。


デプロイツール

rsyncぢゃだめ?

いろいろと「デプロイツールの利点」とか聞くのですが。特に「容易に巻き戻せる」とか。

正直、デプロイで「巻き戻し」っておいちゃんの感覚的には「極めて稀」な事象で、かつ基本的に「手順で1つ2つ、致命的なミスがあった結果」だと思っているので、その部分で「利点」言われても、いまひとつピンとこないでふ。

DBのマイグレーションも同様。

なので、多分これからも「困った事象に直面」しない限り、rsyncベースで進めてくような気がするなぁ正直。


総括

全体としては、Dockerとかのような感じのノリが、わりとしっくりくる感じ。

Dockerそのものについてはなんか見てると(実装の完成度とかの点で)賛否があるようなのと、まだ触ってないのでそこにはふれませんが。

「基本となる考え方/発想」的には、おいちゃんは大変に「好みだなぁ」と感じた次第でございます。


困ったときに「道具をつかって困りごとを解消する」のを、必ずしも否定はしないのですが。

「いあまる道具は なぜこの形を しているのか?」( http://d.hatena.ne.jp/gallu/20080827/p1 )という考察は、道具を使うときには、必要不可欠でございます。

この辺をすっかりと失念して「できるからいいでしょ」で使うと、大抵、ロクなことになりません。


また道具ってのは「必要最低限を適切に使う」ほうが、作成物の仕上がりがよろしくなるのではないか、と愚考いたします。

道具の乱用を留め立てするつもりはないのですが、経験上、それやると大抵「ひっちゃかめっちゃかになる」ので、個人的には避けたいなぁ、とか思っています。


以上、現場から雑感をお送りいたしました。


[][]サーバ系ツールに関する雑感(実践変)

いろいろあると思うのですが。おいちゃんの想定している運用は…多分、 http://www.publickey1.jp/blog/14/immutable_infrastructure_1.html にある、 http://www.publickey1.jp/blog/14/imm04.jpg の絵がとても近いような気がするのですが、こんな感じ。

とりあえずAWS用語を使うので、他のクラウドなら適宜読み替えてくださいませ。ンなに固有の機能は使わないので。


登場人物

ELB:Webのロードバランサ@AWS。「ロードバランサ」と読み替えていただければ、大抵のところでイケるんじゃなかろうか、と。

ec2:いわゆるヴァーチャルなサーバインスタンス@AWS。これも「サーバインスタンス」って読み替えていただければ以下略。

AMI:マシンイメージ。これもAWS。サーバインスタンス作る元ねた的なもの。これも大抵あると思うので以下略。


初手

・必要と思われるdaemonを一式いれて「基本AMI」を独自に作成

・「基本AMI」から、開発用のサーバ、いるんならステージングサーバ(おいちゃんはよく、開発用サーバに共存させちゃう)、本番用のサーバ(とりあえず1台を仮定)をそれぞれ作成

・ELBを適切に紐付けます*1。本番サーバは、一旦「本番サーバテスト用ELB」に紐付けておきます

・開発サーバで適宜開発が進んでいる、と仮定します

・適当なタイミングで、一旦「これをデプロイしませう」なブランチなりなんなりを、ステージングサーバに持ち上げます。具体的には、おいちゃんは「ステージングサーバで、masterなりdevelopなりdeployなり、適切なブランチを git pull する」程度

・ステージングで適宜確認

・本番サーバにデプロイ。おいちゃんは「あらかじめ用意してあるrsync叩く」程度。このタイミングで、本番サーバは「本番サーバテスト用ELB」と紐づいている

・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する

・本番サーバのインスタンスを「本番サーバテスト用ELB」からはずして「本番用のELB」につなげる


以降のプログラムソースのデプロイ(開発中も、本番時も)

・とりあえず1台、AMIから新しく鯖インスタンスを作成 → 新鯖

・「新鯖」に、ステージングのソースを一式デプロイする

・新鯖を「本番サーバテスト用ELB」に紐付ける

・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する

・新鯖をcopyして、「現在、本番用のELBにぶら下がってる鯖と同じ数の新しい鯖(理由があるならインスタンス数を増減させてももちろんOK)」を作成する。これを「新鯖群」と呼称

if(ELB的なものの「接続ドメイン」がスイッチできるのなら) {

 ・「本番用のELB」と「本番サーバテスト用ELB」のドメインをスイッチ(スワップ)する

} else(スイッチできないのなら) {

 // 幾分スピード勝負なんで、バッチ的なもので処理をするとよりよいように思います

 ・新鯖群を一通り「本番用のELB」に紐付ける

 ・旧鯖群を全部、一気にはずす

 ・新鯖群を「本番サーバテスト用ELB」からはずす:ここは落ち着いて、少々タイムラグがあってもよし

}

・不安なら、旧鯖群の1台を、AMIとかでスナップショットっておく

・1時間くらい様子をみて、問題なさそうなら、旧鯖群のインスタンスを全部削除する


daemon等のupdate

・新しいAMIつくる。「0から作る」でもいいんだけど、既存最新のAMIから作ったほうがいろいろと楽

・新しいAMIから新しい鯖インスタンスを作成、開発環境で使って「問題ない」事を確認する

 →あたらしいAMI作る

 →あたらしいAMIからインスタンスを1つ作る

 →開発を一旦停止、ソースは全部gitにしまっていただく

 →開発DBの中身をダンプする

 →新開発鯖にDBの中身を入れる

 →ソースコードを新開発鯖にpullする

 →開発ELBの向き先を「新開発鯖」にする

 →開発を続ける:不具合があったら適宜対応をする

・ステージング鯖を作り直す:開発鯖とおおむねいっしょ。

・本番鯖を作り直す:「以降のプログラムソースのデプロイ」と手順一緒


DBの変更:テーブルの追加

・開発鯖で確認

・ステージングでとっととcreate tableして確認

・本番鯖DBには「ソースコードあげる前」にとっととテーブル作っておく(使われないだけだから、エラーは起こさないし)

DBの変更:カラムの追加

・開発鯖で確認

・ステージングでとっととalter tableして確認

・本番鯖DBには「ソースコードあげる前」にとっととカラム追加しておく(使われないだけだから、エラーは起こさないでしょ?)


DBの変更:INDEXの追加

・開発鯖で確認

・ステージングでとっととalter tableして確認

・本番鯖DBのもとっととalter


DBの変更:テーブル/カラムの削除

・まずそもそも、削除なんてそんなに頻繁にあるの?

・開発鯖で確認

・ステージングで確認

・本番鯖に、まず「修正後のコード」をデプロイする

・デプロイ後、問題がおきなければ、本番鯖DBのテーブルを消すなりカラムを消すなりする


基本はこんなところかなぁ、と。

これで「どうしてもにっちもさっちもいかない」ような状態は、とりあえずおいちゃんは経験ないのと、だから「比較的レアケースなんじゃないか?」って思うので。

レアケースなら、レアな時くらい「1時間程度のメンテナンス停止をかけて作業」でもいいんじゃないかなぁ? っと。


「どうしてもにっちもさっちもいかない」が恒常的に発生するようなケースなら…むしろ話を聞いてみたいなぁ、と思います(笑

*1:開発用ELB、(作ってるんならステージング用のELB、)本番用のELB、あと「本番サーバテスト用ELB」を、それぞれ、こさえておきます。開発ELBは開発サーバに紐付けておきます。ステージング用ELBがある場合、ステージングサーバに紐付けておきます