※本記事は、技術書同人誌博覧会(2019-07-27)にて頒布した「新刊落としましたペーパー」の抜粋です。
続きを読むMicrosoft MVP 再受賞(2019)
Microsoft MVP (Azure)、なんとか3年目の今年もいただくことができました。
相変わらずいろいろふわふわした立場ですが、また一年頑張っていきます。
過去の：
Slack情報収集のためのチートシート
モヒカンSlackなどに限らずSlackをRSSリーダーのように使っている人が多いと思いますが、特定の分野の情報を追いかけるときの覚え書きです。
基礎
SlackではRSSアプリでスラッシュコマンドが用意されているので、一度アプリを登録しておけば、フィードを追加するときは以下のコマンドが使えます。
/feed subscribe ＜RSS等のURI＞
RSSフィードのURI
だいたい以下を追加しておくと良いです。＜keyword＞は目当てのキーワード（"azure"とか"javascript"とか) に置き換えます。
- はてなブックマーク
http://b.hatena.ne.jp/search/tag?q=＜keyword＞&users=3&mode=rss
※ 最低はてブ数を変えたいときはusersをいじる - Slideshare
https://www.slideshare.net/rss/tag/＜keyword＞ - Qiita
https://qiita.com/tags/＜keyword＞/feed
その分野で精力的に情報発信している人が居れば、以下のURIでQiitaやSlideshareがストーキングできます。
- Slideshare
https://www.slideshare.net/rss/user/＜username＞ - Qiita
https://qiita.com/＜username＞/feed.atom
あと、個人的にはDevelopers.IOも追いかけてます。
- https://dev.classmethod.jp/category/cloud/＜keyword＞/feed/ とか
特定のブログを追いかけたいときは、メジャーどころなブログエンジンなら、ソース開いて「feed」とか「atom」「rss」あたりを検索すればRSSフィードのURIがmeta要素とかに入っているので、そこから持ってきます。
Dockerのログ出力先
ツイートしてて自己完結してしまったので記録のために。
あーそういや今更だけど、stdoutとstderrはまとめてlogging driverに渡されちゃうのか。どちらなのかはdriverには渡っているのでfluentdに出せばラベル付いてるので、ログのことだけ考えれば仕組み的にはどちらに出しても扱うこと自体には問題が無さそう。
— Aki (@nekoruri) June 22, 2019
デーモンアプリケーションで想定外のエラーが出うるのであれば、構造化ログをstdoutという分離は全然ありうると思う。
— Aki (@nekoruri) June 22, 2019
でもそうしちゃうとエコシステムから外れちゃうので、やっぱり最大公約数としてはparseableなテキストでstdout/stderrかなあという気がしてきた。やはりDockerにfile descripterの概念が欲しい。チャンネル2個じゃ足りない。
— Aki (@nekoruri) June 22, 2019
理想論はさておき、現実的にはやはりコンソールアプリならstderr、デーモンアプリケーションならstdoutに構造化ログ(JSON)を出してlogging driverで振り分けてparse、stderrは想定外の非構造化エラーログに備える、が万能そう。
— Aki (@nekoruri) June 22, 2019
Dockerを使う最大のメリットは、その「踏み込んだ割り切り」という制約によるエコシステムなので、エコシステムから外れた時点で負けなんだよなあ……。Railsで車輪ガン無視しても別にアプリ書けるけどそれRailsじゃなくていいよねって話と同じ。
— Aki (@nekoruri) June 22, 2019
前提と考察
- Unixの世界では、stdout(標準出力)とstderr(標準エラー出力)という二つの出力チャンネルが標準として提供されている。
- Twelve-Factor Appでは、アプリケーション側はログをイベントストリームとして出力し、実行環境側のほうで開発環境であればstdout、運用環境ならばfluentdなどに送って処理するべきとされている。
- 近年[要出典]のログは、そもそも古臭いNCSA combinedアクセスログのような複雑怪奇な正規表現で取り出すようなテキストではなく、最初からJSONやLTSVなど構造化されたデータとして扱われるべきものである。
- Dockerではコンテナのログをlogging driverという仕組みで処理し、stdoutとstderrを1行1エントリとしてloggin driverに送る。logging driverは標準出力なりFluentdなりAWS CloudWatch Logsなりに送る。
- コンソールアプリでパイプ使う場合は、docker runに-aでstdoutだけ出力できるので、きちんとやる必要があれば出力はstdoutでパイプにつなぎ、ログはstderr経由でloggin driver送り、という使い分けができそう(未確認)
参考リンク
sourceでstdoutかstderrか取れる。
SORACOM Discovery 2019で登壇します(Serverless × IoT)
もう「サーバーレスだけどサーバあるじゃん」という話をしたくない
3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1。
一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。
これを真面目にやろうとすると、キューやPub/Subによる非同期タスク（イベント駆動）が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。
その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさんでてきます。そういうゼロからスケールできるフルマネージドサービスの性質もサーバーレスと呼んでいます。
メリットが分かりやすいためクラウドベンダーが主張したいのはこちらの性質なんですが、でもこれって「所有せず利用する」というクラウドコンピューティング全体の流れの延長線上でしかないんですよね*2。
この設計と運用の二つの性質が混ざったのが現在の「サーバーレス」です。
というわけで、サーバーレスという単語に関しては、
× サーバが無い
○ プログラマがサーバを気にしない
◎ プログラマがサーバを(設計上)気にしてはいけない＋(運用上)気にしない
と捉えるのが良いと思います。単純に「サーバが無い」というだけの解釈をしやすいのは事実なので、こういう理解をした方が楽しいよ、という話です。
日本語圏だとサーバと言えばサーバマシン（ハードウェア）を指すことがほとんどですが、英語Wikipedia見ると、サーバマシンよりも先にクライアント・サーバにおける提供側の"a computer program or a device"が先に来ますし、サーバの仮想化はVirtual ServerではなくVirtual Machineなんですよね。この英語と日本語でのニュアンスの違いが大きいのかなという気はします。
（追記 2023-12-17：正直名前として良くないとちょっぴり思ってはいます）
という話をまとめて書いてあるのでみんな買ってください😇
追記
(2019-05-11 10:00)
あまり記事の意図が伝わってない感じなので、脚注に書いていたことを本文に組み入れました。
こんな読まれると思っていなかったのでポイントをあまり気にせず書いていたのですが、伝えたいのは以下の2点です。
- サーバーレス（Serverless）という単語にも理由があるし、サーバマシン、サーバプロセスへの依存排除というこの抽象化の世界は面白いので、そう単語自体を否定しないで欲しい。
- 「こういう背景もあるのか」ということで一定の納得をしてもらい、この名前の話はとっととやめて、サーバーレス技術を使っていかに楽に楽しくシステムを作るかの話をしたい。
(2023-12-17 18:00)
薄い本へのリンク、もう4版がでているのでそちらに切り替えました。
