woshidan's blog

そんなことよりコードにダイブ。

第1回 技術書同人誌博覧会で「あの素晴らしいCGIからもう一度」というWebサーバとWebアプリケーションサーバに関する入門書と既刊を出していました

こんにちは、無職の犬です。

このエントリは、第1回 技術書同人誌博覧会で出した同人誌のご報告です。

gishohaku.dev

norakann.booth.pm

どんな本だったのか

今回新しく出したのは「あの素晴らしいCGIからもう一度」というWebサーバとWebアプリケーションサーバに関する入門書で、いまはBOOTHにあります。

どんな本だったかというと、

  • Linuxの仕組みを交えつつ、Webサーバアーキテクチャの「いかにたくさんのHTTPリクエストを受け付けるか」あたりの入門を丁寧にやっていく1章
  • Webサーバから転送されるリクエスト(のデータ)を処理するWebアプリケーションのプロセスをどう用意するか、いわゆるアプリケーションサーバやリバースプロキシのお話をCGIからやる2章
  • CGIは実は仕様でもあり、RackやPSGIといったWebサーバとWebアプリケーションがやりとりするときの仕様の先代のような立ち位置でもありました。
    • というわけでPSGICGIを題材にあげ、いまのWebサーバとWebアプリケーションの間の中間層がどうしていまのような感じになっているのかを追いかける3章

という構成で、Webサーバがリクエストを受け付けてから、アプリケーションがレスポンスを生成するコードを呼び出すまでの感触がなんとなくつかめる感じになっています。

技書博には他に既刊のネットワークスクランブル3種も持っていっていて、4種合計でだいたい100冊ちょっと手に取っていただけたみたいです。

woshidan.hatenablog.com

5月に電子版を出していた「ネットワークスクランブル TCP編」の紙版も新しいといえば新しいです。

どんな人にオススメなのか

想定している対象読者はこういう方々です。

  • RailsやLaravelの入門を済ませて次はWebサーバの仕組みについて勉強してみたいな、と思っている方
  • RackやPSGIに興味があるんだけど、抽象的であまりぴんとこないな、という方
  • fastCGIや最近のアプリケーションサーバCGIと何が違うの? という方
  • nginxとUnicornRailsを動かしているけど、どうしてnginxやUnicornが必要なのかはっきりしないかも、という方

もうしわけありませんが、今回はCGIの気持ちになることはたぶんできません。もしかしたらUnicornの気持ちが少しだけわかるかもしれません。

今回はCGIの気持ちにはなることはたぶんできませんが、本の作りは前回と同じく

  • 基本1トピック1ページ前後の短くやわらかめな文章
    • 「人気サイトではたくさんのアクセスあるからリクエストたくさん捌きたいよね」といった前提知識があまりいらないところから始まる各章の構成
  • 「これから読むトピックの主題はここですよ」と一文で伝え、読む前にはガヤやガイドの、読んだ後にはリマインダの役割を果たす印象的な見出し
  • 徹底的に参考文献を明記しながら説明を進め、ニュアンスを伝えるためとはいえ私見が強い部分ではその旨を明示
    • このせいで脚注がうるさくなっていますが、気になる方はepub版だと脚注が全部後ろに行ってるので安心です

という感じで、夏休みの息抜きにおすすめの一冊です。

「あの素晴らしいCGIからもう一度」のもう少し詳しい内容

名前から内容があまり想像できないと思いますので、BOOTHに貼っている見出し+立ち読みページの綺麗な画像にて雰囲気をご確認ください。

f:id:woshidan:20190731145246j:plain

f:id:woshidan:20190731145321p:plain

f:id:woshidan:20190731145333p:plain

f:id:woshidan:20190731145357p:plain

f:id:woshidan:20190731145412p:plain

f:id:woshidan:20190804001412p:plain

上記のような内容で、前回の少し変わったやわらかネットワークプロトコル入門書「ネットワークスクランブル HTTP/TLS/TCP」と一緒にBOOTHにて販売中です。よろしければ「スキ!」だけでもいただけるとすごい喜びますので一度のぞいていただけますとさいわいです。

norakann.booth.pm

最後に、技書博では運営スタッフの方、ご来場いただいた参加者の方、ご近所のサークル主の方のみなさまに大変おせわになりました。

第2回の開催も決定したそうで、次の機会でもお会いできることを大変楽しみにしています。現場からは以上です。

第一回技書博で頒布した「あの素晴らしいCGIからもう一度」紙本初版の修正と「ネットワークスクランブル TCP編」初版の補足

第一回技書博で頒布した「あの素晴らしいCGIからもう一度」紙本初版の修正と「ネットワークスクランブル TCP編」初版の補足です。

gishohaku.dev

norakann.booth.pm

norakann.booth.pm

会場やブログでフィードバックをくださった方、ありがとうございました!

「あの素晴らしいCGIからもう一度」紙本初版の修正

1.1.3.1 節の脚注の修正

修正前

後から動的に確保される部分はヒープ領域https://brain.cc.kogakuin.ac.jp/~kanamaru/lecture/MP/final/part06/node8.html

修正後

後から動的に確保される部分はヒープ領域[メモリの 4 領域 | 2004年度マイクロプロセッサ演習 第6回 (工学院大学講義資料)]。そういえば、この辺に関してどうも調べてみた感じ、データセグメントにヒープ領域が含まれるかどうか、が一定でない気が。。本書での説明では、[メモリの 4 領域 | 2004年度マイクロプロセッサ演習 第6回 (工学院大学講義資料)],や[プロセスのメモリ | 筑波大学工学部電子・情報工学系 システム・プログラム 講義資料]に乗っ取って、データセグメントにヒープ領域が含まれる、としています。とりあえず、本書の内容として重要なのは、「プロセスはプロセスごとにアドレス空間を用意するが、スレッドは同じアドレス空間を複数のスレッドで共有する」「アドレス空間が切り替わるごとにページテーブルとページテーブルの内容をキャッシュするTLBのエントリを入れ替える」「メモリ消費量の件もあるが、TLBのエントリ入れ替えが重いのでその分プロセス切り替えはスレッド切り替えより重い」「スレッドはアドレス空間のうち、スタック領域とガードページは共有しないが他の領域はスレッド間で共有する」なのでそこを抑えていただければ!

p.28 select-acceptのThundering Herd => select-accept型の「Thundering Herd」問題

3章冒頭に以下の注釈を追加

この章は、小学生~中学生の頃に趣味のオタクとしてHTMLやCGIをさわったりテキストサイトを巡回していた自分の思い出と、[CGIプログラミング 第二版]や[README For PSGI-Doc-JA]の記述に基づいてまとめられています。当時の自分のCGIについての思い出、というと「あの頃のオタクのテキストサイト、みんなBBSやリロードするだけで回るアクセスカウンターのCGIをおそらく理屈をそこまで理解せずあれだけ設置してた人がいたの、もしかして異常だったのでは?」といったものです。また、参考にした文書はCGIをポジティブに宣伝する意図があったり、PSGIの仕様を制定された方の視点でまとめられた経緯であったりします。なので、第一回の技書博の場でもフィートバックをいただいたのですが、業務などでCGIを本格的にさわっていた方とは感覚が違うのではないかと思います。自分としては、偏りがあったとしてもこれからPSGIやRackの仕様を学ぶ人への手助けとなるようにまとめているつもりなのですが、もういわゆるCGI全盛期から20年くらい経ちYahoo!ジオシティーズをはじめとした当時のCGIを利用していたサイトがかなり減っていて調査にも限界があるのは事実です。なので、よろしければ「自分から見た当時のCGIはこうだったよ」とbibro.pcg[at]gmail.com宛てであったり、TwitterやQiita、ブログなどで流していただけると喜んでみにいきますので何卒よろしくお願いします。

2019/08/01 追加の修正

1章序文にて

追記 2019/08/04

2.1節にて。

HTMLを吐き出す => HTMLを含めたHTTPレスポンスを吐き出す

「ネットワークスクランブル TCP編」初版の補足

monmon.hatenablog.com

こちらの感想記事の

(どうでもいいけど CLOSING ステータスについては一切触れてないのはレアケースだから省いたのかな? ていうか CLOSING ステータスって両者が同時にFINを送りあった場合にのみ遷移するステータス、で合ってる? まあどうでもいいけど…)

の部分を受けての補足です。

技術書典6で「ネットワークスクランブル」という少し変わったネットワークプロトコルの入門本を出していました

こんにちは、無職の犬です。

このエントリは、技術書典6で出した同人誌とその続編のご報告です。

techbookfest.org

norakann.booth.pm norakann.booth.pm norakann.booth.pm

どんな本だったのか

今回出したのは「ネットワークスクランブル」というネットワークプロトコルに関する少し変わった入門書です。

HTTP編、TLS編、TCP編の3種類があり、HTTP編、TLS編を技術書典6に出展し、TCP編の電子版を5月24日にBOOTHでリリースしました(HTTP編、TLS編もBOOTHにあります)。

3種類の本それぞれの特徴を一言で言うと

  • HTTP編: データ配信の高速化のアプローチ別にHTTPの仕様とその関連技術をからめてご紹介。各章後ろの方が新しい要素となっていて、3~5章のラスボスがHTTP/2。
  • TLS編: ステップバイステップ図解TLS1.2ハンドシェイク(文字中心ながらTLS1.3にも対応)。
  • TCP編: RFC793をベースにウィンドウの範囲を決める変数やソケットAPIに少しだけ踏み込んだ、実装できそうで実装できない、少し実装できそうなTCP

となっています。

どんな人にオススメなのか

想定している対象読者はこういう方々です。

  • RailsやLaravelの入門を済ませて次はWebサーバの仕組みやネットワークについて勉強してみたいな、と思っている方
  • Real World HTTPやプロフェッショナルSSL/TLSといった厚い本を読んだけれどいまいち掴みきれなかった感覚のある方
  • インターネットを支える基礎について勉強してみたいけれどまとまった時間がなかなか取れない方
  • 通勤電車や晩酌のお供にHTTP/TLS/TCPの気持ちになりたい方

どうしてこういう人たちにオススメなのか

本書はオタクの趣味の同人誌ということもあって、以下のような方法で構成されており、肩の力を抜いてお楽しみいただけるようになっています。

  • 基本1トピック1ページ前後の短くやわらかめな文章
  • 「光の進む速度には限界があるからサーバはユーザと物理的に近い方がいいよね」(HTTP編1章)のように前提知識があまりいらないところから始まる各章の構成
  • 「これから読むトピックの主題はここですよ」と一文で伝え、読む前にはガヤやガイドの、読んだ後にはリマインダの役割を果たす印象的な見出し
  • 徹底的に参考文献を明記しながら説明を進め、ニュアンスを伝えるためとはいえ私見が強い部分ではその旨を明示
    • このせいで脚注がうるさくなっていますが、気になる方はepub版だと脚注が全部後ろに行ってるので安心です

また、メッセージのやりとりなど、文章だけではわかりにくい部分には適宜図を入れ(特にTLS編2,3章とTCP編6章)、インターネットとすこし仲良くなれる仕上がりになったのでは、と自負しております。

商業誌に比べると、図が手書きだったり製版に未熟な点もございますが、その辺りはご愛嬌ということで。。

各編の詳しい内容の説明

とはいえ、実は一冊1500円で同人誌としてはそこそこ悩むお値段ですよね。ということで、HTTP編/TLS編/TCP編のそれぞれについてもう少し詳しい内容を説明します。

HTTP編

WebサーバとWebクライアントのやりとりを規定するHTTPには多くの仕様があり、HTTP/1.1を紙に印刷すると176ページ近くになるそうです。

その中にはさまざまなものがありますが、本書ではこのうちHTTP/1.1のキープアライブやHTTP/2のストリームをはじめ、効率的にネットワーク通信を行うために制定された仕様をとりあげます。しかし、HTTPだけでWebページがスムーズにダウンロードされるようになるわけではありません。

かつて利用されたCSSスプライトといった開発者コミュニティ内で生まれた工夫であったり、TLSのセッション再開など他のプロトコルの改善、ユーザの近くからコンテンツを配信するCDNの登場など、HTTPを使った効率的なデータ配信にはHTTP以外にも多くのことが関わっています。

そこで、HTTPの仕様を説明するにあたって、HTTPの仕様と関連する要素をデータ配信を効率化するアプローチごとにまとめたものが本書です。

HTTPと関連する他の要素を、その要素や年代別ではなく「データの配信元をユーザの近くにする」「同じ情報をより小さいデータサイズで送る」などのアプローチごとに古いもの、単純なものから新しいものに並べて論じることでそれぞれの仕様が出てきた背景を実感しやすくしています。

扱っているテーマは

  • 1章 ユーザの近くにファイルを配置する
  • 2章 TCP, TLSのハンドシェイクに関するRTTを減らしたい
  • 3章 同じ情報を小さいデータサイズで送る
  • 4章 リソースやリクエストを並列に送りたい
  • 5章 ブラウザがレンダリングでつまる前に取得順序やタイミングを調整

で、2章ではHTTP/2へのプロトコルアップグレード、3~5章では、HTTP/2の仕様であるHPACK, ストリーム、サーバプッシュも取り上げます。

TLS

TLSのハンドシェイクって具体的に何をやっているか知っていますか?

TLS1.3においてハンドシェイクのフローが単純化されたといわれていますが、現状TLS1.3の普及率は2019年5月3日時点で14.2%*1でまだまだTLS1.2の利用が中心です。

そこで本書は、TLS1.2のハンドシェイクについて「このメッセージのこのフィールドがあの目的で使われている」というハンドシェイクメッセージの各フィールドの意味について、

  • 通信路の暗号化のための準備
  • 通信相手の認証

といったTLSの機能ごとにその背景となる暗号技術の概要をそえて整理しました。

機能ごとのハンドシェイクメッセージの中身を眺めた後にTLS1.2のハンドシェイクのフロー全体を図で確認し、最後に文字中心となりますがTLS1.3でこのフローがどう変わったのか説明します。

ハンドシェイクとは関係ありませんが、なぜAEADが必要となったのか、パディングオラクルの様子を眺める4章もそこそこ気合を入れました。

TCP

上の方で書いた通りTCP編のコンセプトは「RFC793をベースにウィンドウの範囲を決める変数やソケットAPIに少しだけ踏み込んだ、実装できそうで実装できない、少し実装できそうなTCP」で、少しだけ詳しいTCPの本です。

詳細を説明する場合、話が長引いて今何をやっているのか見失いがちですが*2、各章で話が成り立つ程度に後の章の内容を簡略化し、章ごとのメインテーマに集中する、といった構成で対応を試みています。

たとえば、3章でウィンドウサイズの詳細を伏せてウィンドウ制御でデータをやり取りする際の流れについて話を進め、4章でウィンドウサイズの決定方法について詳しく説明するといった具合です。

一つの章を読み進める度に前の章で少しモヤモヤしていた部分が晴れて少しだけTCPの世界が広がる感覚を味わっていただけたらなぁ、と思って構成してましたが、どこまでできたかはわかりません。

また、HTTP/2のストリームのステータス遷移はTCPのコネクションのステータス遷移に近いといわれてピンとこなかった方がいらっしゃいましたら、TCPのコネクションのステータス遷移についてたっぷりの図で説明した6章がおすすめとなっております。

これまでの様子のご報告と今後の予定

本の内容紹介はこれでおしまいですが、技術書典6の際に宣伝してくださった方がいたため、お礼も兼ねてここまでの頒布部数をご報告すると

  • 技術書典6 HTTP 約210 / TLS 約195
  • 技術同人誌再販Night HTTP 7 / TLS 7
  • BOOTH HTTP 35/ TLS 36 / TCP 2

で、500部弱でした。無名無職の趣味オタクの本にしては健闘しているのではないでしょうか。みなさま本当に本当にありがとうございます。

toranoana-lab.hatenablog.com

こちらのブログでもHTTP編について

HTTP通信でよくある問題や課題について、RFCや、最新状況を元に説明されている本です。 理路整然と筋道立てて説明されるのでわかりやすかったです。 Webに関わる人は読んでおくと役立ちます。

とご紹介いただきとても嬉しかったです。

今後については、これから生やす予定のWebサーバについての新刊、誤字やレイアウトを修正したHTTP編、TLS編の紙本2版*3TCP編の紙版を7/27の技書博に持っていく予定です。

gishohaku.dev

もし紙の本がご入用な方がいらしたら、こちらでお待ちしております。

長々と書きましたが、それではみなさまネットワークスクランブルへようこそ。

*1:https://www.ssllabs.com/ssl-pulse/ にて2019年5月25日確認

*2:もしかして自分だけだったらすみません...

*3:TLS編の初版についてはレイアウト崩れがひどかったため、表紙写真をメールで送っていだけますと電子版pdfを無料で送付させていただいています。気になる方はご利用ください。詳しくは https://woshidan.hatenablog.com/entry/2019/04/17/174415

ネットワークスクランブルHTTP 2版物理本に対する訂正

woshidan.hatenablog.com

2版紙本の(及び1版紙本)にて上記エントリに追加で以下の修正が見つかりました。

電子版では修正されていますが、物理版は修正が間に合いませんでしたので必要に応じて下記をご参照ください。

ページ数 訂正前 訂正後
p.12 ところでTCPのハンドシェイクでは、最初にSYNセグメントを送ったクライアントとサーバからSYN+ACKセグメントを受け取るクライアントが一致しない場合、コネクションが確立されません。これを利用すると、コネクションが確立できるかどうかによって、クライアントが送信元IPアドレスを偽装していないかの確認ができるわけですね。この送信元IPアドレスの真偽確認により、たとえば犠牲者のコンピュータへ大量のレスポンスをサーバに返送させるリフレクション攻撃のようなセキュリティ上の危険を防いでいます。 ところで、TCP Fast Openではハンドシェイクを経ずにアプリケーションデータを送信できます。ということは、いきなり大きなアプリケーションデータのついたSYNセグメントをたくさん送りつけることでサーバのメモリを比較的簡単にあふれさせることができそうですね。
p.12 IPアドレスを偽装してないよ 一度ハンドシェイクをきちんとした相手だよ
p.12 具体的には、偽装してないかの確認でもある初回ハンドシェイクの時点から 具体的には、初回ハンドシェイクの時点から
p.13 サーバに送信可能です。 サーバに送信可能です。サーバはCookieが有効な場合のみ、データをバッファに格納します。
p.26 ファイルパスなどの設定でできる? Webサーバでgzip圧縮用設定を行う際にファイル形式の指定を行うなどの形で可能です[久保達彦・道井俊介(2016)『nginx実践入門』(WEB+DB PRESS plus)、電子版「動的なgzip圧縮」、技術評論社]
p.29 15番 14番
p.51 // style.cssについてはサーバプッシュを行わないが、script.jsについては // style.cssについてはサーバプッシュを行わないが、script.jsについてはサーバプッシュを行う
p.51 HTMLのドキュメント本体の処理と並行してHTMLが必要とするリソースを先読みさせるというものです。 そして、ブラウザ上で動くWebサイトなどのアプリケーションから見た場合、ブラウザがHTMLのパースと並行して先読みするリソースの順序を調整する、というだけで両者に違いはありません。 この挙動はServer Pushのものとよく似ていて、どちらのリクエストに対するレスポンスもブラウザをはじめとしたユーザーエージェントにキャッシュされます。また、どちらで取得されたレスポンスに対する処理もクライアントがキャッシュと合致するリクエストを投げたときに実行します。
p.62 しかし、肝心の実装状況がFirefoxではバージョン58で対応されています が、Google ChromeについてはChromiumの関連issueがオープンのまま未対応という状況なので、 実装状況についてはFirefoxではバージョン58やChromeにて対応されていますがすべてのブラウザでサポートされているわけではないので*1

*1:初版紙本で参考にしていたbugのissuehttps://bugs.chromium.org/p/chromium/issues/detail?id=789599は放置されているが、425 Too Earlyのサポートのリリースノートhttps://chromium.googlesource.com/chromium/src.git/+/58097ec3823e0f340ab5abfcaec1306e1d954c5aを見つけたので変更

技術書典6で頒布したネットワークスクランブルHTTP編とTLS編の訂正

技術書典6で頒布したネットワークスクランブルHTTP編とTLS編の訂正で、以下は再販予定の2版では修正されています。 ご確認いただけますとさいわいです。

基本的に「誤り」=>「訂正後」で、脚注番号やページ番号は訂正前のものをさします。

HTTP編

TLS

  • p.13 「年ごろまで」 => 「2003年ぐらいまで」
  • p.14 「検証速度上昇」 => 「計算速度上昇」
  • p.26 脚注 https://qiita.com/angel_p_57/items/437ca6235defc938b97d => https://qiita.com/angel_p_57/items/f2350f2ba729dc2c1d2e
  • p.27 結構書き換えました。。
  • p.39 「要約データを偽造しにくいように、元データを1bitいじったときにどうなるか予測しづらい」の後ろの部分を削除
  • p.39 図A => Fig.17, Fig.18
  • p.40 図A => Fig.18
  • p.41 TLSの復号時にエラーにならなければ => TLSの復号時にパディングに関してエラーにならなければ
  • p.42 GCMやCCMといったAEADが利用されるようになる前のTLSにおいて、パディングの長さが正しければ一旦その先処理へ進むことができます。 => goのtls眺めてみましたがやっぱり消しておいてください。
  • p.42 図Aの式 => Fig.18の図
  • p.42 脚注 「PKCS#7」=>「PKCS#7 パディング」
  • p.61 脚注 RFC7249 => RFC4279
  • p.43以降の図のキャプション
    • p.43 Fig.18「MACと暗号文の生成の仕方」 => Fig.19「MACと暗号文の生成の仕方」
    • p.47 Fig.19「TLS1.2のフルハンドシェイク(クライアント認証なし)」 => Fig.20「TLS1.2のフルハンドシェイク(クライアント認証なし)」
    • p.48 Fig.20「DHE鍵交換DHE認証のハンドシェイク」 => Fig.21「DHE鍵交換DHE認証のハンドシェイク」
    • p.49 Fig.21「RSA鍵交換RSA認証のハンドシェイク」 => Fig.22「RSA鍵交換RSA認証のハンドシェイク」
    • p.51 Fig.22「TLS1.2セッション再開(セッションID)を行う場合のハンドシェイク」 => Fig.23「TLS1.2セッション再開(セッションID)を行う場合のハンドシェイク」
    • p.56 Fig.23「TLS1.3のフルハンドシェイク(クライアント認証なし)」 => Fig.24「TLS1.3のフルハンドシェイク(クライアント認証なし)」
    • p.67 Fig.24「TLS1.3の鍵スケジュール(一部省略)」=>Fig.25「TLS1.3の鍵スケジュール(一部省略)」
  • p.62 「詳しくは6.4節にて。」=>「詳しくは6.5節にて」

TLS編 修正後の目次

節番号の誤りが多いので訂正後の目次を載せておきます。

f:id:woshidan:20190417173648p:plain:w300

f:id:woshidan:20190417173705p:plain:w300

f:id:woshidan:20190417173724p:plain:w300

TLS編 p.27 周りの修正

p.27の内容は、メジャーな本でしばしば言われている「鍵共有では公開鍵で暗号化して秘密鍵で復号」「電子署名では秘密鍵で暗号化して公開鍵で復号」に対するノラカン説みたいなもので*1、第二版では論旨をもっとよく伝えるために改稿した上で独自研究である旨を明記しました。そのため、差分がちょっと大きいです。

もし、TLS編の修正内容について気になる方がいらっしゃったら、レイアウト崩れの件もありますし、初版のp.27表紙を写真に撮って「ネットワークスクランブルTLS」というタイトルの空メールを bibro.pcg[at]gmail.com まで送ってくださると二版のpdfを先着220名まで、メールもらった日の次の土曜日日くらいまでに送ります*2

*1:他の節と違って節全体の参考文献がないという形で1版でも独自研究であることを示してはいますが

*2:ワンオペなのでご了承ください

JAWS-UG コンテナ支部 #13 に参加しました

ちょっとバタバタしていたため遅くなってすみません。。

jawsug-container.connpass.com

上記にブログ枠で参加したので各発表についてまとめます。

AWS サービスアップデート

toricls さんの発表でした。

EKSのTokyoリージョンおめでとうごさいます!

Kubernetes関連を勉強しはじめだったのでアップデート内容についてはうなずくしかできない...という感じだったのですが、re:Inventのアップデート内容の中で、DNSについて、SQSキューなどのリソースのURIを固定にするためRoute53にCNAMEレコードをたくさん登録したことがあったのであとで試してみたいと思います。

今日から始める人のための Kubernetes on AWS ベストプラクティス 2018版

mumoshu さんの発表。

https://www.slideshare.net/mumoshu/kubernetes-on-aws-2018

まさに、これからKubernetesAWSでさわってみようかな、と考えていたので、各種ツールのアプローチやできることの差異などが非常に参考になりました。

特に前半について、KubernetesAWSで動かすための選択肢として、kops, kube-aws, EKSの選択肢があげられていたのですが

  • 連携しているツールの違い(kops: Terraform/kube-aws: CloudFormation/EKS: SDK, CLIの手作業ベース , kubeconfig(まだ貧弱))
  • サポートしているホストOSの違い(kops: いろいろ/kube-aws: CoreOs/ Container Linux)
  • ツールで扱える範囲(kops/kube-aws: マスタ+ノードの運用少し, EKS: Control-Plane*1の構築、運用)

など、一筋縄でいかなさそうです...。

AWSで仮想コンピューティングが行えるサービスとしては、Lambda・EKS・ECS(Fargate)がありますが、それらの使い分けについて触れられていたのも助かりました。

後半はまた改めてお世話になると思います。本当に濃かったです...。

Kubernetes Scheduler のカスタマイズ

チェシャ猫さんの発表。EKSの話ははじめてだったのでついていけるか不安だったのですが、ECSの復習からはじまったので非常に助かりました!

LTがわりの連続Tweetの最初のアドレスはこちら

メンバーごとのリモートで試せる開発環境を用意したい場合*2に、常にメンバーの人数分のEC2インスタンスを立ち上げていても無駄なので、もしすでにDockerのタスクが動作しているインスタンスがあり、余裕があるなら新しいタスクもそちらに配置するようにしたい、という場合にEKSではどう設定したらいいか、について*3

KubenetersのPod*4のSchedulingは、

  • 配置しようとしているPodの条件に合うNodeをフィルタリングする
  • 残ったNodeを優先度にもとづいてスコアリングする

の二段階で行われています。

EKSを利用する場合、上記を実行するSchedulerの指定が行えませんが、追加のSchedulerを指定することで追加の指定を行うことはできます。

しかし、これも追加のSchedulerをPodごとに用意する必要があったりで煩雑なので、Scheduler Extenderの利用が考えられます。

が、こちらは実行タイミングの問題でEKSのデフォルトのSchedulerでフィルタリングされたNodeを選べない、などややこしく、こういった状況にたいして Scheduling Framework が開発されていますが果たして、という内容でした。

犬でもわかった気になってしまった!!

Firecracker とは何か

理解できているか自信ないですが、今回の発表の中で一番面白かったです。

https://speakerdeck.com/pottava/what-is-firecracker

  • アカウントごとにGuest OSのリソースを確保して動かすから従来のLambda(EC2利用)はリソースの無駄な確保もあり、遅かった
  • アカウントごとではなくプロセス単位で分離できていれば十分なのでより細かくリソースを分離、既に起動しているGuest OSを利用できるので早くなる

くらいのノリで理解していました。

発表とは直接関係ないですが、あとで見返す時用にスライドの4ページの各層についてメモを置いておきます。

  • Our code ... 人間が扱いやすいようなレベルに抽象化された命令が書いてある
  • Lambda runtime ... コードの実行環境。(各種サンドボックス相対パスから見て)Lambdaは特定のバージョンのPythonが実行できるようにライブラリなどを決まったパスに入れている
  • Sandbox ... 外部から受け取ったプログラムを保護された領域で動作させて、システムが不正に操作されるのを防ぐセキュリティ・システムのことをいいます。この決まった領域内(多分usrディレクトリ以下はOKでsys以下はだめとか、そういう)にLambdaの実行環境を構築する https://blog.codecamp.jp/sandbox
  • ゲストOS ... ハイパーバイザによって実行されているOS. Macの中にWindowsが!!! とか?
  • ハイパーバイザ (hypervisor) とは、コンピュータの仮想化技術のひとつである仮想機械(バーチャルマシン)を実現するための、制御プログラム https://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%91%E3%83%BC%E3%83%90%E3%82%A4%E3%82%B6
  • ホストOS ... ハイパーバイザを動かしているOS

Envoyを分かりやすく例えつつApp Meshの話をします

_mpon さんの発表。

https://speakerdeck.com/mpon/envoywofen-kariyasukuli-etutuapp-meshfalsehua-wosimasu

App Meshどころか、envoyすら初見だったのですが、nginxでできることに合わせて説明されていたのでめちゃくちゃ助かりました...。 マイクロサービス方面についてもっと調べてみようと思います。

GameDay @ re:Invent のこと

chie8842 さんの発表。

GameDayに行った際、英語がうまく話せなくても自分の担当領域の作業を見つけて実行していく様子や優勝したときに採点されたポイントに他のチームがあまり気づいていなかった話が聞いてて参考になりました。

EKSのいーかんじなサービス公開方法

sugimount さんの発表。

https://speakerdeck.com/sugimount/expose-service-eks-externaldns-acm

EKSでは外部に公開しようと思った時にELBの利用が必要で、その具体的な手順のまとめでした。お名前.comなどからドメインを予約するところから始まっていてありがたかったです。

Virtual Kubelet + Fargate + EKSでノードレス Kubernetes を夢見た話

bbrfkr さんの発表。

https://speakerdeck.com/bbrfkr/virtual-kubelet-plus-fargate-plus-eksdefalsedoresu-kubernetes-womeng-jian-tahua

Kubernetes外のAPIにPodの作成を依頼可能、ということはkubuletが属しているクラスタの外部(たとえば、今回だとEKSのMasterに対してリクエストを投げている)にリクエストを投げられる、ということだったのですが、今回初めてMasterも含めて1つのクラスタの中に構成していく、ということの方を知ったので*5精進せねば...と焦る感じでした。

ECSばかりさわっていて、この辺の話を聞いたことがなかったので大丈夫かな、と思ったのですが、わかりやすい発表が多くてとても助かりました。

*1:kubectlコマンドの結果を受け付けて、そのコマンドによるリクエスト結果をクラスタに反映させるために常駐しているプロセスのことをさすみたい

*2:マルチテナント化、といった用語で説明される状況が恐らくこれ

*3:ECSではBinpackで設定すればよいみたいです

*4:同じ仮想ENIを利用するコンテナの集合。 Webサーバとログサーバを1つのPodに入れて扱うなど。ECSでいうとタスクに近い

*5:https://ja.wikipedia.org/wiki/Kubernetes など

AWS Web Servicesを使ったサーバーレスアプリケーション開発ガイドを読みました

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

上の本を読みました。全体的に

  • Lambdaになれました
  • Vueになれました*1

という感じなのですが、個人的に特に気になったトピック2つだけ並べておきます。

サーバレスで何をやるにしろまずIAMのことを考える件

  • サーバレスのサービスを利用する

と書いてあったときにやる手順が、

  1. AWSサービスへの信頼ポリシーがインラインポリシーとして埋め込まれたロールを作成する
  2. サーバレスで実行したい関数で使う予定のリソースへのアクセス権限を記述したポリシーを書く
  3. 1.のロールに2.のポリシーを付与する
  4. 関数実行時のロールとして3.のロールを指定する
  5. (あるいは0.)Lambdaで実行したい関数などを書く
  6. 5の関数をデプロイして実行

となっていて、サーバレスをやるぞ、といったときに、想定しているのが5とか6だけだったので、自分がAWSに慣れてないだけかもな、と思いつつも、サーバレスよりまずIAMだなぁ、と思いました。

いや、自分で実行するタイミングとか制御しにくくなるので権限管理は余計に大事なんですがが。

めんどくさがっていても仕方ないので、せめて

  • Lambda
  • CloudFormation

の2つについては、それぞれ何をするサービスで、どういう権限が必要かをざっくりまとめておきます。

Lambda *2

使い方

あらかじめPython3.6など特定のバージョンの特定の言語のプログラムが動かせる実行環境がいくらか用意されているので、利用する実行環境を指定して、zipなどでコードをアップロードする。

実行条件はSDKからの呼び出し、タイマーでの設定(CloudWatchを利用)、他サービスでのイベント駆動(S3にファイルがアップロードされたらメタデータが入ったJSONを引数に実行開始、的な)などがある *3

与える必要のある権限
  • 連携先のサービス(たとえばS3に)に与える権限で、Lambda関数へのアクセスを許可するための権限( lambda:InvokeFunction )
  • 実行するコードでアクセスするリソースへのアクセス権限
  • ログを吐くためCloudWatchへのアクセス権限

CloudFormation *4

使い方

AWS CloudFormationを使うと、設定ファイルを書くことで、AWSのリソースの集合をスタックという単位で壊したり更新したり作成したりできるようになります。

ひらたくいうと、AWSが用意したYAMLで書けるTerraform*5で、大きな特徴として、必ずデプロイ用の設定を保管するS3のバケットを用意する必要があります

Lambda + DynamoDB, API Gateway など、サーバーレス向きサービスだけ利用する場合は、SAMというサーバーレス用のフレームワークを用いて簡潔に記述できます。

与える必要のある権限

CLIで実行している間は開発者がなんでも権限を持っていたりするので気にならないんですが、CIの工程にCloudFormationによる環境構築を含めるときには

  • package コマンドで作成した設定ファイルetc. をアップロードするS3のバケットへのアクセス権
  • CloudFormationで操作する予定のサービスのアクションの許可(たとえば、DynamoDBをいじる設定を書いたのにDynamoDBを作成、削除、取得する権限がないと実行できない)
  • IAMパスロール
  • CloudFormationの変更セット*6を作成するための権限*7
  • Lambda関数などサービスのリソースのロールにポリシーをアタッチ/デタッチするための権限(iam:AttachRolePolicy / iam:DettachRolePolicy)

などが必要です。細かくは、本の p.246~ に例があって勉強になりました。

DynamoDBについて

本書を読んで

という具合に「RDSはLambdaに向かない」の意味を理解して、スキャンなどのAPIもさわって理解した気になっていたのですが、

などのスライドを見ていると、トランザクションの整合性に対する理解が特に弱いし全体的にまだよくわかっていないな...という感じなので精進します。

そういえば、indexを貼ってないキーでの検索はフルスキャンが強調されていますが、indexを貼ってないキーで検索するとフルスキャン、というのはRDBMSでもそうですね。

Kinesisについても触ってはみたもののよくわかってないな、という気持ちがあるのでがんばっていくことにします。

現場からは以上です。

*1:フロントエンドから直接データストア触ることが増えるんだったらバックエンドの人も何が起きてるのか調べるために最低限フロントエンド読めた方がよさそう、と思いましたがほどほどに頑張ります

*2:https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-s3-example.html

*3:テスト用のイベントデータ作成に困った時はコンソールでテストイベントの設定をクリックして出てくるイベントテンプレートのサンプルが便利です http://www.atmarkit.co.jp/ait/articles/1706/13/news008_2.html

*4:https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-s3-example.html

*5:作成、更新するときは、deployコマンドの前にpackageコマンドを実行するのですが、そうすると更新しようとしている内容を出力ファイルに吐き出してくれます。Terraformがapplyだろうがplanだろうがこれから更新する内容に差分があればコンソールに出力するようになっているので、え、何も出さずに更新するの? と最初少しビビりました

*6:https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-create.html

*7:CLIで同一のスタックに対し変更 => 再package & deploy を実行していたものの、変更セットについては特に意識せずに終わったので、CLIでスタックを更新する時は裏で作成されているっぽい