makotan _at_ gmail dot com

キューとかDBとか非同期とか分散とか

元ネタはさておき、過去見た色んな物をメモする

プログラムの中のメモリーキュー

プログラム上に用意したメモリー上のキュー
作るのは簡単だし使うのも簡単
モリーの容量制限があるので大量に詰まると大変なことになる
監視が面倒なので気をつけて使おう

サーバのインメモリーキュー

Redisとかそういうの
容量的にもインメモリーなので辛かったりする
とはいえ、意外と便利
絶対的に速度が必要で容量が大丈夫なときにはベスト

キューサーバ上のキュー

ActiveMQとかそっち系
2PCなキューとか作れるキューなのでDBとの同期とかもやる気になれば出来る(色々ハマるけど)
普通にキューを作るんなら多分一番楽だと思ってる

クラウド上のキュー

SQSとか
順序保証なにそれ?とか複数取得出来たりするので実装をだいぶ気をつけないとヤバそうなやつ
それに合わせて実装を頑張ればなんとか出来る
かなり大きいけどリクエストの上限があったり、容量制限がすっごい緩かったりする感じ
最近FIFOオプションとか対応してきてだいぶ良くなってる

ストリーム

最近多くなってきた感じのやつ
大量のリクエストを受け取れたり一定時間保持できたり再処理できたりするサービス
クラウドとオンプレの両方に同じようにある
シャーディング出来るので普通のキューで耐えれないほど大量のリクエストを処理する場合に有効な感じ

DBのキュー

キューというよりポーリングでの実装なのでこれをここに入れるのはちょっと違う気がする
ステータス管理しようが何しようが、普通に作るとDBのロックを使うのでDBへの負荷が結構になる
RDB使っていれば別のサービスとかサーバとか使わなくて良いので追加サーバをようしなくて良くなるのはだいぶ大きいメリット
ただ、この中では唯一と言って良いSQLで不要なメッセージを削除できる能力があるので上手く使うとそこはとっても良い

使い道とか

リクエストに投入する量とかコンシューマの数とかスケール性とかそれ以外の特性を決めると大体何を使ってどういう風に作れば良いのかが決まるはず
なので前提条件を決めずに特定の物をダメと言ったり代替案にするのもいまいちかなぁ〜って思う今日この頃

社員の採用の検索とか書類チェックをしてる人から聞いた話

最近採用関係をやってる人が凄く近くに居るので、その人から聞いた話のメモ

書けない情報もある

NDA違反になるような情報は絶対に書いちゃダメ。
面接の時に言うのも基本的にNG

期間が空いてるとき

就職と就職の合間の1ヶ月間休みましたとかはどうでも良くて
半年とかそれ以上の期間が無職状態で空いてるときは何らかの理由があった方がお互いにフィルターになるので良い

やりたいことを書く

今は出来なくても将来こんなことしたいとかの展望、野望、希望を書く
特に年齢の低い転職の時にはいっぱい書いた方が良い

やりたくないことも書く

最近はSES契約は嫌だとか言う人が多いらしい
そんなことも含めてやりたくないことは明記する方が良い

今できることを書く

今までのキャリアから今できること、転職先から期待してもらえることをしっかり書く
ここ意外と大事らしい
あんまりない年齢の低い転職の時には先輩から評価されてるポイントとかをアピっとく

必須の条件も明記する

転職先が満たしてないとダメそうな所を明記する
この辺に希望年収とか色々
お互いのフィルターになる

しょぼいミスしない

チョットしたところのミスに気をつける
転職の書類っていうわりと人生の大事な書類にミスがないように数回チェックした方が良い

これまでの経歴はざっくり

こんなのを作って、こんな役割で、こんな物を使って、この期間で作りました
って言うのが並んでれば基本的にOK
全部アピールポイントがある人はそんなに居ないはずなので、面接の時の話のネタにしたい奴を中心にするのもあり
経歴が大量にあるときは、転職したい会社の近いキャリアの物を集中投下すると良いと思う
それ以外はほんとにざっくりまとめる
年齢の低い転職の時は逆にアピールポイントを捻出するのを頑張る

まとめると

いっぱい書いた方が良いよ

NASが壊れた

記録によると2011年には使ってたので仕方ない気はする


急ぎのものはないとはいえ、全てのデータへまるっとアクセス出来ない!
ということで色々調べたところ・・・同じメーカーのNASを買ってきて入れ替えれば良いらしいということまで判明
取り急ぎ新しめの機種で欲しいものをリストアップしたので後は選んでポチるだけ←イマココ


ふと考えた
イマドキNASなんてローカルに置かなくても良いのでは??
HDDが2Tなので、とりあえず2Tとして計算しようかと思ったけど実際には1Tも入ってないので・・・計算を楽にするために1Tで
まずは仕事で何かとお世話になってるS3(オレゴン)、NASの代わりなので、低頻度アクセスストレージで$0.0125/GBで$12.5/TB
GoogleDrive \1300/TB(S3をドル換算すると現状はこっちの方が安い)
OneDrive (Office 365 Soloの値段) \12,744/1 年 1Tのストレージ付きなので今のところ最安値というか、これでOfficeも使える!んだけど・・・businessにしかNASが対応してないから使えるか不明


という感じでここまでは1000円位のOneDriveが最安値なんだけど・・・
S3なら使った分だけ課金なので、実際に500G位ならS3が安いって事になる


さて、本命Glacier
$0.004/GBで$4.0/TB
桁が違ってて圧倒的に安かった。
代わりに取り出しにお金がかかったりするのでホントにアーカイブ向けのストレージなのでNASクラッシュの時のバックアップ用って意味合いで使うには良いなと
たまにアクセスするならGCPのColdline辺り(価格は倍近いけどS3の低頻度アクセスストレージより安い)かなと。


ということで、用途別にまとめるとこうなった
純粋なバックアップストレージとしてだけ使う=Glacier
たまにネット経由でも同じデータを取得したい=S3,GCPのColdline,OneDrive for Business
Officeのライセンスも必要でたまにネット経由で=OneDrive for Business
音楽データがメイン=GooglePlayMusic+何か


部屋の模様替え実施中で結構な出費予定があるのに、さらにNASですか・・・
次にNAS買ったらもうファイル保存用のNAS買わない(Time Machine用は除く)ぞと心に決めた
(まだポチってない理由はどれにするのか再検討する&模様替えの途中のため)

(追記)
さくっとNASポチった

マルチサービスデータベース

年の瀬にぼんやり考えてた


Aurora、Redshift、Athena・・・
と色々とSQLを使うサービスが登場してるわけですが
それぞれ特性が異なってるためにデータを入れ替えつつ使い分けをするそんな日常


これらの上位にSQL対応のDB Proxyサービスを設置
データは種類に応じて定期的に各々のサービスにコピーされていく(マスターはAurora)
SQLを投げると、その対象期間とかSQLの内容に応じて自動的に実行するサービスを切り替えて実行
通常は普通にAurora or PostgreSQL、沢山の集計処理とかが入る場合はRedshift、Auroraに無い古いデータを見る時はAthena、対象が古くて且つ沢山の集計処理の場合はRedshift Spectrum
みたいなのを自動的に判断して実行


って言うのがあれば良いのにな


このサービスいつAWSが出すのか教えて!エライ人!

2017年振り返り

総括すると良い一年でした



趣味でwebなアプリ作ろうとしてたけど、結局画面の無いアプリ作ってる
webアプリ作ろうとするとめんどくせぇ〜ってなってそのめんどくささを解消したくなるので致し方ないw



比較的健康な1年、比較対象は周りの人w
周りが頭痛とか腰痛とか何かと痛そうな人が多いのでそれに比べるとアレルギーくらいだし健康だなと
過去の経験から、あとは健康的に瘦せれば小さい問題も片付く


お仕事大変
色んな想定外がいっぱいの1年
あと、昔仕事で作ったサービスが想定外のところで使われててびっくりした


勉強がすすまなかった
年始に色々勉強しようとしてたのがあんまり進んでない
ゲームに時間吸い取られすぎた気がしてる。来年はGTとエースコンバット位しかしないつもり


片付け進んだ
10年ほど続いてる断捨離ブームの結果、家の片付けがだいぶ進んだ。
ゴールはさらに荷物を数割減なのでもうちょい先だけど、大きなマイルストーンまではあと少し!
この後がなかなか大変そう・・・

だいぶ前にぼんやり考えてたメールサービス


細かいの端折ってまとめると
相互認証をした間とその派生の間で信頼性と秘匿性の高いメールネットワークを構築する
ドメインはサーバも独立してて、ドメインの信頼と公開鍵をブロックチェーンで管理する
あるドメインから大量のゴミメールが流れてきた場合にはブロックチェーンに記録して全メールサービスでブラックリストを共有
A-B, B-Cで相互認証をした場合、A-Cの相互通信も可能
Cが大量のゴミメールを送ってブラックリスト入りした場合、Bの信頼が低下する
ある程度信頼が低下したドメインブラックリスト入りする
メールの送受信の時には宛先情報は相手の公開鍵で暗号化、本文は自分の秘密鍵を使ってキーを暗号化する
鍵を変更したい場合はブロックチェーンに記録する
これを今のSMTPの上に載っける(=これを使わなければ普通のメールになる)


こんな風にやればだいぶ安全なメールサービス作れそうだけどなぁ〜
ってぼんやり考えてた


コンセンサス・アルゴリズムどうするかってところで思考停止したのは秘密
プルーフ・オブ・ステークになるだろうけど、コインじゃ無いしメール配信に採掘が必要ってのもなぁ・・・