たまごかける日報

ここにAA貼りたい

Cloudflare と Fastly で wasm on edge の素振りと雑な所感 🦀

クリスマスですね

どうも、メリークリスマス🎄🎅🎄
会社のアドベントカレンダーにこんな日記みたいな記事を書いてしまって死にたみが高まる @kakerukaeru です。

最近のぼく

去年ぐらいから、Cloudflare が Edge 上で JavaScript を実行できるようにする Cloudflare Workers を発表したかと思えば、Akamai も負けじと Edge Workers を Edge Conference で発表したりして、今までの面倒な CDN の Configuration からより Dynamic な Routing だったり Caching の設定を Code で表現出来るようになってきてて夢が広がるなぁ〜と思いつつ、Cloudflare Workers を遊びでちびちび触ったりしていた。

ちなみに、Akamai の Edge Workers は楽しみではあるんだけど、まだまだ private β っぽくて触れるようになるのはまだ先かぁといた感じだったので、触ってない。Cloudflare Workers は既に本番でも使えるし、無料で遊べる場所もあったりlocal で debug 出来る仕組みも整ってあるので興味があれば触ってみて欲しい。結構簡単に挙動の変更ができるので触ってて楽しいと思う。

そんな中、とはいえ一旦 vcl でいいや〜と fastly をちまちま本番導入してたりしたら、Cloudflare が Cloudflare Workers を WebAssembly に対応させるわと発表したり、Fastly Workers とか来るんじゃね〜と冗談をいってたら Worker をすっ飛ばして Fastly も WebAssembly 対応するわと言う発表が今年の年末にかけて飛び出してきた。

今まで CDN 上での HTTP Request を Rich にハンドリングできる Worker だったり vcl だったりとは違い、(本当に wasm にそんな事をさせるのか?という事はさておき)使える module の制限はあるものの、API と static resources さえ用意できれば、簡単なサイトの Rendering を edge で完結できるのではという様な違う方向にも夢が広がり始めた。

wasm on edge

普段自分が仕事で関わってる領域でいうと、冷静に wasm をゴリゴリ使う様なシーンはまだまだあまり想像できないんだけど、なんとなくどんな使用感なのかは知っておきたくて、一旦触ってみることにした。

wasm 自体は初心者だったので、一旦 Rust 🦀 and WebAssembly 🕸 チュートリアルを掻い摘みつつ...

Cloudflare de wasm

先程、Cloudflare Workers は 無料の遊び場 があるって言ったんだけどこの子は wasm に対応してないので、Cloudflare の Account を作成して Worker を有効化した環境($5/Month)を用意してからじゃないと試せない。

Worker は遊び場の感覚で設定するとして、wasm は compile 済みの file を何がしかで upload する必要がある。Resource Binding APIAPI 経由で upload する形式と、Worker の edit 画面から GUI 経由で upload する方法がある。

今回は使用感を知りたいだけなので、GUI からポチポチ file を uload する方法を取った。 bind した module をどうやって呼び出すのか一瞬わからなかったけど、upload したときの名前で呼び出せるみたいだった。結構簡単

f:id:kakerukaeru:20181224161133p:plain
isqrtという、variables nameでwasmをuploadしてるのがわかる

設定してた worker はこんな感じ。特になにもない。

let instance = new WebAssembly.Instance(isqrt, {});

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

/**
 * Fetch and log a request
 * @param {Request} request
 */
async function handleRequest(request) {
  const url = new URL(request.url);
  const num = url.searchParams.get('num') || 1;
  let squareroot = instance.exports._Z7Q_rsqrtf(num);
  return new Response(squareroot, { status: 200 });
}

Fastly de wasm

Fastly はまだ production には出てないが、最近発表された Fastly LabsTerrarium で wasm on edge が遊べるようになっている。Cloudflare と違って compile 済みの file を upload するのではなく、fastly 上で build を走らせるぽい。そして、ホスト側の機能を叩けるように faslty 側で用意してくれてる http_guest の Code も公開されていた。でもなんで Rust だけ公開されてるんだろう。

f:id:kakerukaeru:20181224190107p:plain
Browser上で好きなCodeを編集してdeployできる

まだ、sandbox 感が強くて正直どんな感じで本番時に適用させるのか想像がつかないけど、もうちょっと情報公開されてきたら触ってみたい。

もうちょっと触ってみたかったんだけど、サンプルプログラム書き換え〜とかしかする時間がなくて断念した

雑所感

近年 CDN layer で出来る事がどんどん増えていって、昔のただ Cache させるという単純な CDN からどこまで役割を広げるかを悩むシーンが増えてきた気がする。個人的にはまだまだ従来の origin でやっていた WebServer の責務をよりユーザーに近い Edge に負わせて origin の CPU resources の節約と 柔軟な Caching Configuration による Performance 向上といった所までしか考えてはいないんだが、来るべき満塁のチャンスのためにこれからも CDN 界隈の動きを注視して素振りを続けようと思う。

あともうちょっと wasm のもくもく会して、ちょっと Rich なナニカを作ってみたい。

2015の振り返り的なアレ

大晦日

毎年の如くですが、今年も実家に帰っております。
ブログを見てみると去年はインフルエンザにかかってたみたいですね。今年はというと私の母が風邪にかかってしまい一家で年末年始に病気にかかる呪いにでもかかってるのかなと疑ってる私です、こんにちは


今年何やって来年は何を頑張りたいのかな〜とか考えながら自分のブログ見てたら、なんも書いてなくてゲロはいた。

っていうね


今年

仕事回り的な

今年一年のしごと的なアレを振り返ろうとして気付いたのは、今年一回も異動してなかった。
新卒入社4年目だけど1年を通して環境が変わらなかったのは今年が初めてで、抱えてるサービスは相変わらず多いながらも同じサービスに対して半年以上のスパンで継続して関われたのは嬉しかった。今いるのが基盤に関わる部分なので余計にね。

ので、今までとは違った働き方が出来たなと。
特に、ウチの画像配信基盤で抱えてた複数の画像Storage(Voldemort + Swift + WebDAV)を、S3(新規file)+ 独自Storage(Archive file)の構成に変更したのは動き出しから含めて1年以上の長期計画だったので完遂できたのは凄い嬉しかった。レガシーからの脱却とかコスト削減だったりキャッシュと向き合ったりいろいろ楽しかった。

単純な新規立ち上げではなく、ごくアタリマエにあるモノ(特にレガシーの塊的な奴)を改善しながら提供し続けるという難しさみたいなのも実感しつつ学べたしいい経験したな、と。

あとの細かいイベントはうるう秒対応したり、Cassandra Meetup in Tokyo, Summer 2015で喋ったり、Akamai Edge Conference 2015に行かしてもらったり、また会社のAdvent Calendarでクソ記事量産したり、結構好きにやらせてもらって楽しかったなー。なんて。

人回り的な

別に今年に限ったことじゃないんだけど、インフラエンジニアとして尊敬する先輩たちが次の職場で新しいチャレンジを続々としていく状況で、一番の下手くそでいよう派として自分も環境をカエルべきなのか、いやいや自分がココでその立場になるべきなんでしょというのをすごく考えた1年だった気がする。というより、キャリアパスをどうしていくべきなのかみたいな。今は後者で頑張ってる感じ。一周回って考えたんだけど、全然いまも結構な下手くそだった
ので、まだまだやりたい事をどんどんやっていく、、、で!!なんか、エモキモい

来年

去年はちゃんと目標書いてなかった気がする。

  • 英語
  • Blog
  • Code

これかな、、、
Blogというか、アウトプットは本当にしてないと腐る。evernoteに溜め込んだクソクローズドメモとかマジ意味ないなと実感する。ので、少しでも出していく...で

英語は、今年カンファレンスも旅行も含めて海外に行く機会が多かったってのが大きな要因の一つだがエンジニアやってく上で逃げられないなというのを実感してるので目標に...TOEICも受けよう。

Codeはこれからのキャリア的に。ちゃんとかけるインフラエンジニアにならんとなという。こまかくてもいいからGitHubに草生やしていこう。

そんな雑な感じで今年の振り返り終わり。
今年お世話になった人に感謝の気持ちを述べつつ、 良いお年をノシ

おわり

varnishのTransfer-Encodingとのお付き合い的なナニカ

これはVarnish Cache Advent Calendar 2015の21日目の記事です。
ナンカ書こう、と軽い気持ちで参加したらいつの間にか当日になっていました。

何を書くか直前まで迷っていたのですが、最近varnishのAccept-Encodingの扱いでチョト困ったのでその備忘録的なことを書きます。versionは4.1.0-1です。

TL;DR

  • vcl_recvでpipe,passを使っている場合を除き、varnishはdefaultでbackendにAccept-Encoding:gzipを投げる。
    • なんなら、Accept-Encoding:kakeruとか適当にリクエストを投げても、Accept-Encoding:gzipで上書きしてbackendに投げてくれる
  • 奇特な理由があってgzipをoffりたい場合は以下どれかの対応で逃げられる。
    • 起動オプションで、-p http_gzip_support=false
    • vcl_backend_fetchでunset bereq.http.Accept-Encoding;
    • vcl_backend_responseでset beresp.do_gunzip = true;

現象

会社の画像配信基盤のcache層としてvarnishを使わせてもらってるのですが、
とある日にjson fileやcssや画像を配信しているごった煮Backendのみvarnishにcacheさせていなかった所を、他の画像が乗っているbackend達と同様にcacheさせるように変更を行いました。 後日そこの特定Backendへの一部リクエストでエラーがちょろちょろ出るようになっていたので、そこを調べていったよという話。

config変更はこんな感じ

急に出てきたエラーとしては、アプリがTransfer-Encoding: chunkedに対応してないよという感じのエラー。

原因

先に原因を書いてしまうと、以下になる

  • varnishはdefaultでbackendにAccept-Encoding:gzip を送りつけるが、今までpassで設定していたため付与されていなかった。
  • passを外してcachesさせるようにしたので、Accept-Encoding:gzip を付けて対象のbackendへのリクエストを生成するようになった。
  • その対象backendのみ Accept-Encoding:gzip を解釈出来たため、chunked responseを返しアプリであぼんしてしまった。

調査過程

恥ずかしい話、varnishがdefaultでAccept-Encoding:gzip を送りつけるのを把握していなかったので、 誰がAccept-Encoding:gzip を送りつけ始めたのかを調べるところから始まった。

調査方法はみんな大好きtcpdump

passを抜いたことが明らかに原因だったので、
今回はその前後のconfigでの動作の差異を調べる。

ので、varnishが付与してると断定。varnishのgzip回避の設定を調べることに。

ちなみに、
Headerを見たいだけならvarnishlogでも可能。

こっちの方が簡単ですね。

対応

今回の対象backendのみcssjsonなどの圧縮の恩恵を預かりやすいfileの配信を行っているbackendだったが、画像配信基盤全体としての配信内容はほぼほぼ画像コンテンツだったということもあり、画像にgzipは無意味ということでvarnishとしてgzipをサポートしなくても良いかなという結論に至った。

上記を踏まえた対応方法としては以下の3つぐらいかな。

  • varnishのgzipサポートをそもそも切る
    • varnishdの設定で、-p http_gzip_support=false にする
  • varnishがbackendにAccept-Encoding:gzipを送らないようにする
    • vcl_backend_fetchでunset bereq.http.Accept-Encoding;の記述を追加
  • gzipでbackendからgetしてきたコンテンツを解凍してキャッシュとして保存する
    • vcl_backend_responseでset beresp.do_gunzip = true;の記述を追加

今回は vcl_backend_fetchでunset bereq.http.Accept-Encoding;を追加して対応した。
ちなみに、 do_gunzipは本家でも、なんでそんな事すんの?と書かれるぐらいなので、流石にやらなかった。明らかにナンカ無駄感ありますしね。。

http_gzip_supportをoffに関しては、結局はAccept-Encoding:gzipをbackendに送らないようにするだけなので、そっちでもよかったかも

おまけ

varnishはgzip supportをしている & pipe or passを使っていない場合、
どんなリクエストが来てもAccept-Encodingの中身をgzipで上書きしてリクエストを処理するらしい。

されてた。
Accept-Encoding:kakeruとかのアホなリクエストを投げてもちゃんと上書きされてた。
なるほどです。

といった

ただの備忘録ですが、
こんなアホみたいな所で困ってる人の役に立てれば幸いです

おしまい

参考document
https://www.varnish-cache.org/docs/trunk/users-guide/compression.html
https://www.varnish-cache.org/docs/trunk/reference/varnishd.html#varnishd-1
https://www.varnish-cache.org/docs/trunk/phk/gzip.html

渋谷にいるなら一旦コレ食っとけってカレー達

カレー Advent Calendar 2015の18日目
昨日は @kuwa_tw さんだったけど、まだ記事が見当たらないですね?^ー^

諸君、私はカレーが大好きだ

とか、言っちゃったりしてね。
一部の常にスパイスを持ち歩いてるカレー狂いには遠く及ばないが、 私も結構カレーが好き。ということで、良く行かせてもらってるカレー屋を紹介してく。

職場が道玄坂なもんで、道玄坂近辺のお店が多め。

シブマハール

足りない分の写真 #カレーAdventCalendar #シブマハール #ほうれん草うまぁー

@kakerukaeruが投稿した写真 -

ザ・インドカレー
道玄坂のTOHOの横の通りにある。 螺旋階段を上がった2階に店を構えており、ちょっと入りにくいイキフンを漂わせてる。

が、入ったら気のいいおっちゃんが出迎えてくれる。
こういうお店では定番のいわゆる無限ナン攻撃も堪能できる。 ライスとナンを選択出来るのだが、前に一回ライスを頼んでみたらおっちゃんが明らかに「エェ〜('A`)」みたいな顔してたから、ナンがオススメなんだと思う。知らんけど。

個人的におすすめは、
カレーを2種類選べるランチAセットで 🍤 + ほうれん草 の2種コンボ
ほうれん草が絶妙にスパイス効いてて絶品なのだ〜^

マリーアイランガニー

再訪アリ

@kakerukaeruが投稿した写真 -

スリランカカレー
東急本店から原宿方面へ抜ける通り沿いのマンションの5Fにある。
これまた一見さん的には入りにくいイキフンが出ている。
5Fに上がるエレベーターでは、「あ、今地震来たら確実に死ぬわ」というドキドキ感を味わえ、 店内に入るとテレンス・リーみたいな風貌のイカした店長がいて更にビビる。

接客していただいたらとってもフレンドリー
無駄にビビってごめんなさい

オススメは1日5食限定のスペシャルポークカレー
スパイシーなルーを纏ったトロケるポークの肉塊がドドンとお皿に置かれて出てくる。たまらん。
ポークカレー以外のランチで頼めるカレーも基本的にスパイシーだから、スパイシー好きなら是非行って欲しい。

ネパリコ

ねぱる

@kakerukaeruが投稿した写真 -

ネパールカレー
セルリアンタワーの近くにある。

ネパールの家庭料理、らしいけどそんなことよりもネパリコの🍛めっちゃ体に優しい。
今まで結構スパイシーな🍛ばっかの紹介だったけど、ネパリコめっちゃ体に優しい(二回目

オーダーの時に、辛さを3段階(だったかな)選べるんだけど、愚行。
辛味とか入れずに、そのままの美味しさを味わって欲しい。
ちなみに、メニューに書いてる辛さ3段階ってのは無視できるっぽい。 おっちゃんが言うには「20モ、デキルヨ。デモ、タベラレルカナ~~?^^」との事。
この前、10辛食べたけど、それでも優しかった。
20もきっと優しいと思う。

僕は、なんやかんやのドライカレーが結構好きです。

カイラス

ズルカレー

@kakerukaeruが投稿した写真 -

ザ・日本カレー
道玄坂の交番前の道路を超えたルーニーの隣にある

カレー好きだったらやっぱりインドカレーだよね?^^
とかいう一部偏った風潮が昨今見られるが、 海外のカレーばっか食ってたら日本カレーが食いたくなる、そうですよね?(乱暴

安心できる、誰にでもオススメできる味。
まさに母の味的なアレ J( 'ー`)し

個人的なオススメは、
カツカレー + ゆでたまご + 卓上に置いてあるらっきょう
ありがたや🙏

Curry House チリチリ

安定

@kakerukaeruが投稿した写真 -

最高
大好き、とにかく最高

インド流製法を基本にした体調を整えるカレー。と本家サイトでも謳っている通り、かなり整えてくれる。あぁ〜疲れた〜^整えてぇ〜^という時にかならず行く。

食ってる時も体が整っていくのを感じる。 インドカレーウメェ〜、いや、これは最早チリチリ。チリチリという食べ物。チリチリに体整えられてるぅ〜。 今ならなんでも出来る気がする〜^

というように、こいつトリップしてしまったんじゃねーか、と心配になるような感想が出てくるほどウマい。僕の貧相な語彙力では伝えきれない旨さがある。

だから、一旦行こう。
行ってくれ、な?^^

注文は、必ずhogehogeマサラカレーの方を頼んでください。
一旦、ミックスマサラカレーかチキンマサラカレーを頼んでみればいいと思います。  

チキンマサラ、ほうれん草トッピング!

@kakerukaeruが投稿した写真 -


と、いった具合だ。
渋谷には他にも伝えきれない程たくさんの美味しいカレー屋さんがある。
以下、一例を記しておく

書くときりがないので、ここらへんで、、、
店名部分を食べログのリンクにしてるので、 (わかりにくいかな、、、) 渋谷でランチの際には是非参考にして欲しい。

では、楽しいカレーライフをノシ

おわり

Transportable Tablespace@InnoDBを使ってみたよ

最近飲み歩きたい欲が凄い。
そろそろ3大欲求に食い込んでくるんじゃないかと思ってる。
いや流石に嘘だけど。

というわけで、 Transportable Tablespaces@InnoDBを使ってみたって話。

TL;DR

  • MySQL5.6.6から使えるようになったTransportable Tablespaces@InnoDBつかってみた
  • file-per-tableのテーブルスペースとメタデータの転送でデータ移行ができる
  • ので以下の特徴がある
    • データを直接ポンと置くのでmysqldumpとかよりも早い
    • import時にテーブルスペースの破損check、index再構築などをしてくれる
    • 種サーバからメタデータを作るときは、対象テーブルに共有ロックがかかっちゃうよ

経緯

とあるStorageからMySQLへの移行的なモノを行なっていた。

作業用MySQLサーバで種データを作って本番サーバにデータを配布したいんだけど結構全体容量がデカイのでどうするか悩んでいた。出来れば簡単かつチョッパやでオシャレな感じでデータ配布したい。

そんな折に、MyISAMみたいにfileをcopyしてきてデータ移行が出来るTransportable Tablespaceなる機能がInnoDBにあると知り、試してみることに。

みたいな、ざっくりってるから正確にはチョト違うんだけど、こんな感じのが経緯で触らせて頂くことに。

前提

すべてのサーバで

  • MySQL 5.6.6 以降である
  • innodb_file_per_tableがONになってる
  • ページサイズが一緒

対象サーバ
種鯖:10.10.10.10
本番master:10.10.10.11
本番slave:10.10.10.1[2-5]

aho DBにある tmp_?? みたいな正規表現で引っかかるtable * 256個をよそDBにimportしてみよう。

作業

流れ的には

  • 移行先にテーブルつくる
  • 種サーバで一瞬メタデータ作る
  • メタデータibd fileを転送して、移行先サーバのデータディレクトリに展開
  • importする

簡単ンゴ

なんで実際にやったcommand的なアレをメモしておく。

配布先に空のテーブルだけ作って待ち構えるで

### 種サーバ作業
# tmp_??のテーブル定義抜き出して、転送するよ
$ ssh 10.10.10.10
$ mysql -uroot -N -D aho -e "show tables like 'tmp___';" | cat | xargs mysqldump --no-data -uroot aho > /tmp/aho_tmp___.dump
$ scp /tmp/aho_tmp___.dump 10.10.10.11:/tmp

### masterサーバ作業
## tmp_??のテーブルを本番サーバで作るで
$ ssh 10.10.10.11 
$ mysql -uroot -D test -vvv < /tmp/aho_tmp___.dump > /tmp/aho_tmp___.dump.out

## 対象テーブルに排他ロックかけてテーブルスペースを切り離すよ
## つまり、ALTER TABLE {対象テーブル} DISCARD TABLESPACE; のSQLを作って流すよ
$ mysql -uroot -N -D aho -e "show tables like 'tmp___'" | cat | xargs -i echo "ALTER TABLE {} DISCARD TABLESPACE;" > /tmp/aho_DISCARD_TABLESPACE_tmp___.ddl
# 流すよ
$ mysql -uroot -D aho -vvv < /tmp/aho_DISCARD_TABLESPACE_tmp___.ddl > /tmp/aho_DISCARD_TABLESPACE_tmp___.ddl.out

データを種サーバから配るで

### 種サーバ作業
## 共有ロックかける代わりにメタデータ吐き出すよ
## 複数テーブルのメタデータを一気に吐き出して転送したいから、1個のセッション内で作業してね
## FLUSH TABLES {対象テーブル} FOR EXPORT; のSQLを作って実行するよ
$ ssh 10.10.10.10
$ echo -e "ALTER TABLE `mysql -uroot -N -D aho -e \"show tables like 'tmp____'\" | cat | xargs -i echo -n {},` FOR EXPORT;" | sed "s/, FOR/ FOR/g" > /tmp/aho_ALTER_TABLE_tmp___FOR_EXPORT.ddl
$ mysql -uroot -D aho
mysql> さっき作ったSQLをぺろって貼ってね
mysql> まだexitしないでね!メタデータが消えちゃうよ!

# 別セッションで作業するよ
$ ssh 10.10.10.10
$ sudo ls /var/lib/mysql/aho/tmp_??.{ibd,cfg} | wc -l
512
# 確認してみると、tmp_??テーブル256個分のメタデータtmp_??.cfgがちゃんと256個作られてるよ。この2つを転送先サーバに送るから固めよう
$ cd /var/lib/mysql/aho/
$ tar cfv ../aho_tmp_??.tar tmp_??.{ibd,cfg}

## メタデータ込みのデータを固められたから、もうロック解除していいよ。
# さっきのmysqlのセッションに戻ってね
mysql> UNLOCK TABLES;
mysql> exit
# ちなみに、ロックを解除したらメタデータは消えるよ
$ sudo ls /var/lib/mysql/aho/tmp_??.cfg
ls: cannot access /var/lib/mysql/aho/tmp_??.cfg: そのようなファイルやディレクトリはありません

データをimportするよ

### 本番サーバ全台
## importするデータを引っ張ってくるよ
$ ssh 10.10.10.1{1-5}
$ cd /var/lib/mysql/
$ scp 10.10.10.10:/var/lib/mysql/aho_tmp_??.tar .
$ cd aho
$ tar xfv ../aho_tmp_??.tar
# ahoディレクトリ配下に.ibdと.cfgを設置したよ

### 本番masterサーバ作業
## ALTER TABLE {対象table} IMPORT TABLESPACE; のSQLつくって流すよ
$ ssh 10.10.10.11
$ mysql -uroot -N -D aho -e "show tables like 'tmp___';" | cat | xargs -i echo -e "ALTER TABLE {} IMPORT TABLESPACE;" > /tmp/aho_ALTER_TABLE_tmp___IMPORT_TABLESPACE.ddl
$ mysql -uroot -D aho -vvv < /tmp/aho_ALTER_TABLE_tmp___IMPORT_TABLESPACE.ddl > /tmp/aho_ALTER_TABLE_tmp___IMPORT_TABLESPACE.ddl.out
# メタデータはもういらないから、移行が終わったら消しておこうね
$ rm /var/lib/mysql/aho/*.cfg

まとめ的なアレ

悪くないんだけど、ちょっと制限が多いし手順がちょいちょいあって面倒くさい、、、

でも今回、データ移行時にテーブルのカテゴリ別にちまちま分割してimportしてたんだけど、70GB (table30個、各5000万ちょっとレコード) ぐらいの奴がSAS Raid10でimportに40分ちょっとぐらいだったから、遅くない、、、よね??( •̀ㅁ•́;)

メンテ打ってこのテーブルだけ他のSSDの鯖に移すぜ!とかいうシーンだったら重宝するかな?master分割的な?

あとは今回のケースみたいに、 Archives的な基本的に更新のないデータのStorage移行時とかには、移行用テーブルデータの用意が出来たらポンポン本番に追加していくとかには使えるのかな。

的な。
おわり🍺

参考ページ
14.4.6 Copying File-Per-Table Tablespaces to Another Server

Cassandra Meetup in Tokyo, Summer 2015でお話してきたンゴ

はい

フザけたタイトル&半年以上ぶりのブログの更新ですが、先週の金曜日にCassandra Meetup in Tokyo, Summer 2015に出てお話をさせてもらいました。

DataStaxさん、Yahoo! JAPANさん運営お疲れ様でした!& お声かけ頂きありがとうございました!

イカ、資料

内容としてはタイトルの通りとっても初心者向けで、
Cassandraは怖くないよとお伝えする感じのお話でした。
次、機会があったらもっと変な話もしてみたいな。

ちょっといい話?

僕のセリフみたいになっちゃってますが、
Cassandra meetupの最後にoranie様が解き放った言葉です。

まさにこの言葉の通りでCassandraは何をするにしても日本語の情報が圧倒的に少ない。
日本Cassandra界の天下を取るなら今に圧倒的な貢献をするなら今!といっても過言ではない。

みんなでドンドンアウトプットして、 Cassandra Communityに貢献していこう!(^ω^)
というエモい感じで半年ぶりのブログ更新を締めたいと思います。

おわり

2014の振り返り的なアレ

大晦日

今大阪の実家に帰省してるんですけど、
こっそり何も言わずに帰って驚かせてやろうとか思ってたら、
愛媛のおばあちゃんの家に家族が行ってしまってて実家で一人寂しく過ごしてた僕です。こんにちは。

また家族が愛媛から帰ってきたタイミングで40℃超えの熱を出してしまい、みんなにうつるといけないからと離れに隔離されて、年越しカウントダウンをしていますが僕は元気です。
仕事をしてる身としては体調管理的な意味でアウトですね。。。

今年の厄が一気に大晦日に来たと考えれば、逆に幸先良さそうです。逆にね。('A`)ヴァー

今年

前半

色々動いたなという感覚(異動的な意味で)。
今年のしょっぱなに異動をしたのだが、技術的な事をほぼやっていなかった。
自分のスキル不足のせいもあり、上手く動けておらず、
また技術的なモノを一切業務で触っていない不安から日々焦りを感じていた。
好きな検証とかしてみるもののこれで良いのか、エンジニアとしてゆっくりと死んでるのではないかみたいな。

ただ何も学べなかったわけではなかった、
今思うと技術的なモノ以外の、人と仕事をどう進めるかという大事なことを叩き込んでもらった期間だった。

後半

8月ぐらいになって、
新卒1年目の時に所属していた基盤のインフラチームに異動した。

これは運もあったのだが、異動してから2週間後ぐらいで社内チューニンガソンの若手の部門で1位になれた。
これは僕にとって凄く嬉しい事で、手を動かす仕事に戻ったタイミングでこういう賞を取れたのは幾分か僕の背中を押してくれたんだと思う。 その後のISUCONでは惨敗しましたが^p^

また同じチームの@namikawaさんのお誘いによりMySQL Casual Talks vol.7に出たり、CyberAgent エンジニア Advent Calendar 2014にてIT芸人としての第一歩を踏み出したりした。
IT芸人記事の方は今でも良かったのかとビクビクしながら生活をしています。

まとめ

今までのニートエンジニアだった僕からすると外に出たほうなのかな。
さっきの発言とは矛盾するがちびっとだけ外に出たことにより、より日々の焦りが増したと思う。
だが、良い焦りだとも思う。
この気持を持ち続けていかなければいけないと思う、自戒を込めてね。

これからは継続的にアウトプットしていきたい。
これ、去年も同じ事行ってる気がするな。。。
実績ベースのアウトプットはほぼ皆無ですし、🍣

プライベートは本当に書ききれない人に迷惑を掛けた気がする('A`)ヴァー
精進します。。。

今年お世話になった人に感謝の気持ちを述べつつ、
良いお年をノシ

おわり