非テック系22歳になりました。今年(というか当分)のモットーは「而今」です。過去未来に囚われず、今この瞬間を淡々と生きます。去年の梅雨ごろ禅に出会い、「而今」という概念に出会い、これを中心に添えた人生がとても生きやすかったので、今後しばらくはこれを座右の銘として生きたいと思います。而今とは、道元禅師が中国での修行時代に悟った世界観で、意味は「ただ今この瞬間」というような意味です。教えの解釈は人によって多少異なりますが、僕は「食べるときには食べることに徹する、寝るときには寝ることに徹し、つまらないことに囚われて今というかけがえのない時間を無駄にするな」というふうに理解しています。禅との出会い以下ブログで綴ったとおり、去年の春、僕は少しだけ疲れていました。「これは自分のためになるのか?」「今日はどれほど有益だったのか?」という問いが常に頭に蔓延り、締切が定められてるものが1つでもあると何をしててもそのことが頭をよぎり、今やっぱあのこと考えたほうが良いかも?なんて考えてました。今やってることの先にある利益に目線がいっていたわけです。medium.comまた、web業界は発展途上であるが故に若くて経験が少なくてもでも目立てます。インターネットの力を使えば、いわば小手先の戦術的な動きをして「やってる感」を演出することが可能で、そこに何か物足りなさのようなものを感じていました。手軽な労力で得られる充足感は逆に心を蝕むなと思っていた頃、英語学習法の一つである「只管朗読」という勉強法に出会いました。これは同時通訳の神様と呼ばれた故・國弘正雄先生が外国語学習の原点として提唱した学習法で、その内容は「ただひたすら声を出して読むのみ」です。これはただひたすら座るという意味の禅語、只管打坐をもじったものです。1週間くらい続けた日の夜、自分に今一番必要なのはこれだと確信しました。一つのことに集中する作業を繰り返すことで、何か行っている最中にその先の利益について考えないことの素晴らしさを体感できるようになりました。これは野球部時代に行っていた素振りに近いものを感じました。目先の利益に振り回されなくなり、価値があると自分が信じていることに淡々と取り組むようになり、色々なことが良い方向に向きましたが、何より今、一つ一つの瞬間が最高に楽しいです。おわりに過去に囚われることは、波が打ち寄せる砂浜に絵を描くようなもので、描いたと思った瞬間波がやってきて消え去っていきます。栄光であれ黒歴史であれ、一生戻ってくることはありません。考えても仕方ない未来に過剰に心煩わすことは、便器に釣り糸を垂らすのと同義であり、時間が溶けるだけです。今やるべきことは決まっているので、それに淡々と取り組んでいきます。2020年もよろしくお願いします。非テック系2019年ももう12分の1が終わってしまったので、ひっそりとメモ程度に記す。北風と太陽で言えば、去年はほとんど北風だったので今年は太陽を取り入れていくという話。タイトルの通り今年のテーマは「柔よく剛を制す」と決めているが、この"柔"には大きく3つの意味がある。柔軟に頭を切り替える世界としなやかに繋がる遊び心を取り入れる柔軟に頭を切り替える幼少期からとにかく脳が不器用で、一つに集中するとそれしか考えられない。豊かな人生を送るためにもコンテキストスイッチのオーバーヘッドを減らしたい。世界としなやかに繋がる昨年は英語ブログを開始したり、クラウドネイティブ系のOSSの議論に参加したりと、海外と繋がる場面が増えてきた。英語ネイティブと難なくコミュニケーションを取れるレベルまでいきたい。この国は言語の壁によって孤立しがちだが、一歩外に出ると無限の世界が広がっていることを知った。日本で働いていても常に世界の一次情報と繋がっていたいし、世界のトップデベロッパー達と現地で議論したい。OSSオープンな技術の最前線にいると熱狂の毎日を送れることはよく分かった。創作意欲が刺激されてる時が最も興奮するのは間違いないので、学生最後の1年間を思いっきりつぎ込む。遊び心を取り入れる必要以上に自分を取り締まりすぎる傾向があり、どんどん固く細かい人間に近づいている。地元の友だちからも固いと言われてしまった。このままだと自分が作った小さい世界に閉じ込めてられてしまう気がするので、肩の力を抜き、生活に遊び心を取り入れる。さいごに一番好きな一節を以下に記す。あふれる情熱から、人が何ら報酬を受けることなく、ただでも喜んで追求するようなことを職業とする特権を、神はほんの一握りの人間にしか与えてくれないものだ。訳この情熱を絶やさないためにも、もっと燃やすためにも、柔らかく生きていく。moduleという概念について、本人の許可を得てまとめたものです。本書の内容を詳しく紹介するのではなく、主に私の考察を書き綴ったものです。moduleという概念について説明します。良いモジュールとは良いモジュールとはなんでしょうか。ここでいうモジュールというのは、クラス・構造体やサブシステム、さらにマイクロサービス等の分化されたソフトウェアを指し、言語は問いません。beautiful」というUnix哲学があるように、小さいことは価値になります。モジュールを小さく分割することでモジュールの仕事が明確になりやすく、結果的に保守が容易になります。確かにそれは大切なことですが、そもそもなんのためにモジュールを作るのでしょうか?主な理由の一つとして、関係性の高い要素が集まることで実装の複雑さを下げるというものが挙げられます。それを踏まえた上でこのコードを見て下さい。Javaでファイルを開く際、以下のように3つの小さなクラスが必要です。gist.github.comFileInputStreamは初歩的なI/Oのみを提供し、BufferedInputStreamは、FileInputStreamで得られたバイト入力ストリームをバッファリング読み込み付きのバイト入力ストリームに変換します。ObjectInputStreamはシリアライズされたオブジェクトを操作する機能を提供します。見ての通りファイルを開くためだけに3つもオブジェクトを生成しなければなりません。クラスを小さくしたことで、各クラスの仕事は明確になりました。関連性の高いFileInputStreamとBufferedInputStreamが独立してしまっていることで、もしユーザーがBufferedInputStreamを作り忘れた場合はバッファリングされずに遅くなってしまいます。実装の複雑さが外部に漏れてしまっているということです。実装の複雑さが漏れることが必ずしも悪いとは限りません。以下のことは認識しておくべきです。beautifulであることは間違いないのですが、関連性の高い要素を分割してしまうと保守性が下がってしまうことが分かりました。小ささを意識しすぎると良いモジュールは作れないことが分かります。高凝集?疎結合?関連性の高い要素が集まり(高凝集)、それぞれが依存し合わない(疎結合)ことは非常に大切です。上記コードは低凝集・密結合の良い例です。関連性の高いたくさんの要素を隠し持つメリットはたくさんあります。"関連性の高い"要素を持つことで設計が明確になり、保守と拡張が容易になり、再利用性が高まります。"たくさんの"要素をもつことでモジュールの機能が強力になります。"隠し"持つことで疎結合化も促進することが出来ます。よって、高凝集というのは非常に大事な概念だということが分かります。モジュールの疎結合化がソフトウェアに良い影響を与えるのは言うまでもないでしょう。疎結合を保つためには、モジュールを繋ぐインターフェースを良いものにする必要があります。良いインターフェースとは「インターフェースはシンプルに保て」とよく言われますが、このシンプルという言葉は曖昧なので噛み砕いていきます。モジュールのインターフェースに何が求められているのかを理解する必要があります。モジュールが他のモジュールを利用するためには、インターフェースという名の契約を結びます。各モジュールは契約を前提に実装されるので、契約が変わるとその契約に関わっている全てのモジュールの実装を変更しなければなりません。ソフトウェアというものは、ほとんどの場合変更されます。この矛盾の中でも崩れないことがインターフェースには求められています。良いインターフェースとは、不変(追加以外の変更を許さない)なインターフェースだと考えています。可能な限り、インターフェースを利用するユーザーにとって使いやすくあるべきです。Mattersで述べていた考え方に影響を受けています。使いやすさというのは相対的な概念で、何が便利なのかはユーザーによると考えています。ユーザーをユースケースの観点で大きく2つに分けると、エッジケースで利用するユーザーと一般的なケースで利用するユーザーに分かれます。インターフェースが複雑になってしまう主な理由として、エッジケースを許容してしまうということが挙げられます。そのため、一般的なユースケースに絞って使いやすさを追求するべきです。先程のJavaのコードをもう一度見て下さい。ファイル操作時にはバッファリングするのが一般的なケースのはずです。関わらずBufferedInputStreamクラスを独立させることで、バッファリングしないというエッジケースを許容していました。そのためインターフェースが複雑化してしまったということです。良いインターフェースをまとめると、「一般的なケースで使いやすく不変なインターフェース」と考えることが出来ます。上記を踏まえて、私の考える良いモジュールの定義は「関連性の高いたくさんの要素を隠し持ち、一般的なケースで使いやすく不変なインターフェースによって強力な機能を提供するもの」です。moduleという概念について説明します。moduleたくさんの要素を隠し持つためには、ある程度実装は複雑になります。良いモジュールにするためには、実装の複雑さを感じさせないインターフェースで強力な機能を提供しなければなりません。moduleと呼んでいます。本書では以下のように書かれています。modules上図は本書に記載されている図を参考に作成したものです。長方形が一つのモジュールを表しています。上端の横の長さがインターフェースの複雑さを表していて、縦の長さが機能の強力さ(モジュールがもたらす利益)を表しています。横に長ければ長いほどインターフェースが複雑で、縦に長ければ長いほど機能が強力だということです。Ousterhout教授は左の縦長な長方形のようなモジュールをdeepと表現しており、最も良いと考えています。モジュール設計の際には以下の視点が必要だということです。機能は強力だけど、インターフェースも負けないくらい複雑になっていないか?逆にインターフェースは簡単だけど、機能も負けないくらい貧弱ではないか?インターフェースの複雑さというのはコストで、機能の強力さというのは利益です。moduleといえます。この見極めが難しいので、良い例をたくさん見ることが大切です。moduleを体現している例として、Unix系OSのファイルI/Oに関わるシステムコールが挙げられます。標準的ファイルI/Oモデルから外れなければ、使うシステムコールは基本的に以下5つのみです。I/Oの実装は長年に渡って進化し続けているのにも関わらず、この5つのシステムコールは変わっていません。moduleといえます。カーネルは本来ユーザアプリケーションを安定して動作せるために設計されているため、インターフェースがほとんど変わりません。そのため、カーネル周辺のインターフェースをじっくりと眺めてみると参考になると思います。抽象的な世界をコードに落とし込む上に常に変わり続ける「ソフトウェア」というものに、全ての視点を取り入れるのは困難だということは誰もが感じているはずです。moduleについて、一人でも多くの方が理解して頂けたら幸いです。興味を持った方は本書を購入することを強くオススメします。moduleについて知った時、以下ツイートのようなことを考えました。これについては別エントリでまとめるかもしれません。これを読んでたら「良いモジュールは簡単なインターフェースで多くの機能を提供してくれる」と強調されており、任天堂の宮本さんの「アイデアとは複数の問題を一気に解決するもの」という言葉を思い出した。2019年1月6日*間違いやご意見等ありましたら、Twitter等で連絡して頂けると大変助かります。非テック系2018年の様々な「良かった」をまとめました。良かった買物これに関しては、買ってよかったものというサービスにまとめてあるので割愛します。katteyokatta.morishin.me良かったPodcastトータルテンボスのぬきさしならナイト1月に聴き始めて以来、トータルテンボスの大ファンになりました。いのが好きな人にはおすすめです。バイリンガルニュース英語と日本語が入り混じって最新のマニアックなニュースについて伝えてくれる有名な番組です。英語力低い状態で英語をずっと聴いていると段々話題が分からなくなっていくのですが、この番組は途中途中日本語が入るのでリラックスして英語に触れられます。Ueyamaさんが低レイヤの技術についてひたすら喋る番組です。Googlek8sや周辺のクラウドネイティブ技術について伝えてくれる番組です。Kleinが出演したときが神回です。始発で豊洲に行き、4時間並んで食べました。個人的にはブリとしめ鯖で泣きそうになりました。ローストホース会員制なので会員の方に連れて行って頂きました。JINDARIインドで数年間修行を積んだ店主による本気のカレーを数種類食べました。エミリア麺のモチモチ感が異常で、麺が長めなのがまた良いです。六本木本店ささみカツで初めて感動し、一時毎日のように通ってました。疲労を全回復してくれる居酒屋です。肴処やおよろずなかむラー油が購入できるので、仙台行ったら必ず行きたい店です。ブリッコ・ボスキスさすが王様。フォリアージュ・グラン・クリュ・ブラン・ド・ブラン・ブリュットシャルドネ100%の泡。ホシャール・ペール・エ・フィスレバノンのワインを初めて飲みました。一人で行き、白谷雲水峡を登ったり適当にサイクリングしたりしました。屋久島はそこらじゅうにパワースポットなり自然遺産なりがあり、適当にプラプラしてるとこんな場所にたどり着いたりするので、無理に予定入れなくても楽しめました。友人の別荘に泊まり、広大な景色を見ながらひたすら温泉に入りました。東京駅から2時間かからず行けるので、本当に癒やされたいならベストプレイスかもしれません。肌が弱く麻酔が出来ないため気を失うほど痛いけれど、日々のHX(ひげ剃り体験)がかなり向上しました。2018初めてのフェスだったのですが、2つの学びを得ました。当時の自分はカリスマのエンジニアになるという自己実現欲求が前に出すぎていました。そこでNickelbackという最上級レベルの自己実現族を見て、進み方が大きく変わりました。DAOKOを見て、自分の世界観と社会の需要がマッチすることの尊さを知りました。CONtest(いい感じにスピードアップコンテスト)のことで、Webサービスをチューニングして高速化するコンテストです。出場した1392名、528組の中で30組のみが進める本戦に、学生枠という制度を使って進むことが出来ました。詳しくは以下ブログにまとめてあります。nakawatch.hatenablog.comnakawatch.hatenablog.com英語ブログの開始もっと多くの人からフィードバックを受けたいという思いと英語学習を兼ねて、自分の技術ブログを英訳し始めました。これがかなり良く、定期的に英文を書く習慣がつくと、もっと細かいニュアンスを伝えたいという欲求が生まれるため、普段読む英文を見る目も変わってきました。medium.com技術ブログがちょいバズり今までオープンな場で評価を受けたことがなかったので、アウトプットが間違っていないことが確認できて安心しました。Goにて登壇させて頂きました。今後登壇機会も増えてくるので、かなりいい経験になりました。株式会社レキピオという会社に2ヶ月間ほどジョインさせて頂きました。ここで学んだ事と出会った人は素晴らしく、現在の自分の骨にもなっています。Boldスピリットは今でも自分の心に宿っています。自分が組織とパフォーマンスに興味を持ち、クラウドネイティブ技術を追うきっかけとなった場所でもあります。上場前ということで動きも目まぐるしく、最初はメルカリアッテ、次にメルカリメゾンズ、最後はメルカリNOWという様々なサービスのAPI開発に携わらせて頂きました。異動の度にキャッチアップの必要があるので、ひたすらソースコードリーディングをしました。業界を引っ張っている方々のコードを血眼になって読んだことが、ソフトウェアエンジニア中尾涼の血肉となっていることは紛れもない事実です。家よりも温かい空気感に包まれながら開発をさせて頂きました。役員クラスの方々や世界一のソシャゲであるモンストを支えるSREの方々等、中々お会いできない方々とお話する機会がたくさんあり、そこで学んだことの多くが自分の考え方のベースとなっています。業務内容は、AIジムのココサイズという新規事業の決済周りの面白いところを触らせて頂きました。9月〜現在2020年度に新卒として入社する予定の会社です。入って1週間くらいで「ここだ」と思い、すぐに選考に進ませて頂き、内定承諾させて頂きました。前述したように、メルカリさんで組織とパフォーマンスに興味を持ち、ドリームチームでモノづくりをしまくる30代を迎えたいという夢を抱き、クラウドネイティブ技術に興味を持ちました。上げる基盤構築を主体的に行える環境です。希望が叶って配属されたAWAチームはまさに求めていた環境でした。良かった2018年nakawatch.hatenablog.com持ちつ持たれつを宣言して始まった2018年は、マンパワーに支えられて幕を閉じます。「あれってまだ今年なの?」と思うことが多々あるくらい濃い一年でした。来年もよろしくお願いします。Calendarの9日目の記事です。前回は@moomooyaさんのマイクロサービス化にあたって、gRPCを導入しようとしている話でした。Autumnにて発表された「OpenCensusによるAPMの実現と、未来」というセッション名がかっこよかったので、表現を拝借しました。分散トレーシングの必要性マイクロサービスのような分散アーキテクチャは複数のサービスにまたがって処理されているため、サービス間の通信を追跡することが難しくなります。障害発生時の原因究明が難しくなるパフォーマンス低下の原因究明が難しくなるそこで、分散トレーシングツールで可視化して上記の問題を解決する必要があります。分散トレーシングを学ぶにあたって、以下2つの用語は必ず覚える必要があります。EnvoyなのかEnvoyを使わずとも、ZipkinやJaeger等のトレース可視化プロバイダが提供するツールがあれば、分散トレーシングを実現することは可能です。実現のためには、トレース毎の識別子を生成してそれを伝搬していき、最終的にコレクターというコンポーネントに送ることが必須です。そのために各サービスに言語毎のクライアントライブラリを導入して、専用の実装をする必要があります。Polyglotが前提にある分散アーキテクチャであるマイクロサービスアーキテクチャにおいて、これは大きなコストを生む原因になります。そこで、インバウンドとアウトバウンド双方のトラフィックを前提に作られているEnvoyをサイドカーとして配置しておけば、この問題を解決してネットワークとアプリケーションを分離することが出来ます。このような、全サービス間通信をサイドカープロキシを経由させることによってマイクロサービス固有の課題の解決を行うアーキテクチャをサービスメッシュと呼びます。スパン間の親子関係等のコンテキストを適切に伝搬させるためには、アプリ内で特定の識別子を伝搬させる実装をする必要があります。これに関しては後述します。Envoyのトレーシングアーキテクチャ利用するトレースプロバイダにもよりますが、多くの場合以下のようなコンポーネントで構成されたアーキテクチャとなります。プロバイダによってStorageを提供してくれるものもあれば、自前で運用する必要があるものもあります。分散トレーシングでは通常、トレース内で一意の識別子を伝搬させることでスパンを関連付けていきます。この一連の流れの中で、Envoyの仕事は大きく分けて3つあります。トレースの生成とトレースの伝搬、そしてコレクターへの送信です。生成(ドキュメント)tracingオブジェクトを設定することで、トレースを生成することが可能になります。伝搬(ドキュメント)x-request-idという識別子を伝播して、呼び出されたサービス間のロギングを相関させていきます。前述したように、スパン間の親子関係を明確にするためには別の識別子の伝搬も必要です。Envoyはこの識別子をHTTPリクエストヘッダーに乗せて通信します。そのため、特定のヘッダーから識別子を取り出して次に通信するサービスへのリクエストヘッダーに追加する必要があります。少なからずコードの修正は必要になるということです。Envoyにはインバウンドトラフィックとアウトバウンドトラフィックを関連付ける手段がないので、これはアプリケーション開発者の責任だということです。これはトレース可視化プロバイダ毎に異なる識別子が必要になるため、自分が使うプロバイダのドキュメントをよく読む必要があります。執筆時点(2018/12/9)で対応しているトレース可視化プロバイダは以下です。プラガブルになるよう設計されておりドライバを実装するだけで良いので、新たなプロバイダをサポートすることも難しくありません。Zipkin(フォーマットに互換性があるJaeger等も含む)LightStepDataDogドキュメントに従って、トレースを送信するコレクタークラスタを指定します。Zipkinの場合は以下のように定義します。"/api/v1/spans"触って理解するEnvoyは公式のサンドボックスがいくつか用意されています。今回はこの中のjaeger-tracingを触りながら、分散トレーシングの一連の流れの理解を深めていきたいと思います。いう3つのコンテナが起動します。いう順に通信が行われます。可視化ブラウザでhttp://localhost:16686にアクセスして下さい。複数のスパンが一つのトレースとなって表示されているのが確認できます。サービスの実装を変更サービスのサンプル実装はexamples/front-proxy/service.pyにあります。注目すべき実装は以下の部分で、ここで受け取った識別子をヘッダーに乗せて伝搬させています。Propagationというリポジトリにて詳述されています。試しにこの処理をコメントアウトして、再度リクエストを送ってみましょう。スパンがそれぞれ別のトレースと認識されてしまっているのが分かります。スパン間で識別子を伝搬させないと正しくトレースを取得出来ない事が確認できました。全体的なアーキテクチャに始まり最終的にコードを触ることで、大まかな仕組みを理解して頂けたでしょうか?先日(2018/11/28)、EnvoyはCNCFの卒業プロジェクトに認定されました。その時のブログ内でも繰り返して述べられている通り、Envoyの目標は、アプリケーション開発者からネットワークを抽象化してビジネスロジックに集中できるようにすることです。これはEnvoyに限らず、クラウドネイティブが主流になった現代では多くの人が、アプリケーション開発者が創作活動に集中できる環境を望んでいます。2016年9月にLyftがEnvoyをOSSとして公開した時、本人達の想像を超えるほど反響がありました。これは、クラウドネイティブを推進するにあたってネットワークプロキシが非常に重要なポジションを占めていることを表しています。今後アプリケーションからネットワークを抽象化するようなプロジェクトがどんどん立ち上がるとしても、内部では常にネットワークプロキシがアプリケーションに寄り添っているはずです。そのため、プロキシへの理解を深めておくことはクラウドネイティブ時代において非常に大事だと思います。筆者も微力ながら議論に参加していき、アプリケーション開発者にとっての最高の環境作りに貢献していきたいと思います。*間違いを見つけたり情報が古くなっていたりしたらTwitter等でご指摘頂けると幸いです。こんにちは、20卒内定者で現在AWAでアルバイトをしている中尾涼(@nakabonne)です。Meshというアーキテクチャが注目されています。実現のために様々な製品がありますが、私はsxdsという小さなcontrol-planeを作りました。Meshを小さく始める手段について、sxdsを使用しながら紹介していきます。Meshとは乱暴に説明すると、マイクロサービス化することで起きる様々な問題を解決するためのアーキテクチャの一つです。Meshの定義については、様々な記事で紹介されてるので、今記事では割愛します。data-planeそれぞれを実現するツールは、以下のようなものがあります。ここでは執筆時点(2018/12/7)で代表格とされているもののみ説明します。previewとしてのみ利用可能)執筆時点でのcontrol-planeとしてはIstioが有名です。Meshを実現することが出来ます。非常に優れたツールではありますが、もちろん銀の弾丸ではありません。Istioはコンテナオーケストレーションツールからクラスタ情報等を収集することで効果を発揮します。コンテナオーケストレーションツールを使っていない環境では効果を発揮することが出来ません。Istioは多くの機能が提供されていますが、ごく僅かな機能しか使わない場合は同じく効果を十分に発揮することが出来ません。Meshでも使われているEnvoyが、代表格といえるでしょうか。EnvoyはL7プロキシです。特徴は、インバウンドとアウトバウンドトラフィックの仲介を前提に作られているため、分散トレーシングや動的なサービスディスカバリをプロキシレベルで実現出来る点です。優れたスレッドモデルによってパフォーマンスが非常に高いという点も挙げられます。Envoyでは、全てのハードウェアスレッドにワーカーを生成してそれをメインのスレッドが制御しています。C++を選んだのも、そのモデルを実現できる唯一のプロダクショングレードな言語だからとのことです。スレッドモデルに関してはブログに詳しく記載されています。紹介したとおり素晴らしいツールはたくさんあります。私が当初欲しかった機能は、サービスディスカバリのためにdata-planeのルートテーブルを動的に更新するというものだけでした。いうコンテナ管理サービスの上で動いていたため、k8s等のオーケストレーションツールを使っていませんでした。そこで私はdata-planeにEnvoyを採用し、それを制御するsxdsというcontrol-planeを作りました。次の節から作り方を詳しく説明していきます。インターフェースEnvoyと通信するためのインターフェースはdata-plane-apiとして公開されており、ルートテーブルを動的に更新するためにはこれを満たすAPIを作る必要があります。Kleinはdata-plane-apiを汎用的にしていきたいとブログにて発言しています。そのため、将来このAPI定義が汎用的になった場合、自作したcontrol-planeがプラガブルになります。data-plane-apiを満たしたAPIをxdsと呼びます。protocolを定義しています。これに従ってgRPCのbidiストリームかロングポーリングのRESTでxdsを実装します。protocolを忠実に守って実装しないといけないわけですが、GoとJavaのみこの実装が含まれる公式ライブラリが公開されています。envoyproxy/go-control-planeenvoyproxy/java-control-planesxdsではGoを選択し、go-control-planeをインポートしてxdsサーバーを実装しました。GitHubはい、これだけでxdsの実装は終わりです。go-control-planeはdata-planeの設定をメモリにキャッシュする必要があるため、以下のようにキャッシュするためのRESTサーバーも立てています。GitHub全体図はこんな感じです。静的リソースの管理Envoyへのレスポンスに必要な静的なリソースを管理する必要があります。sxdsはLDS/CDS/RDS/EDSという4つのサービスを提供しているため、これらに必要な以下のリソースを定義しておく必要があります。listenersclustersendpointsroutesまた、リソースのバージョンも明示する必要があります。protocolに定義されています。sxdsではこれらをjsonで定義し、前述したキャッシュするためのサーバーにPUTします。GitHubEnvoyの設定sxdsのクラスタ情報は静的なので、static_resourcesとして定義します。そのクラスタをdynamic_resourcesとして指定します。GitHub実行Envoyの実行sxdsはメモリ消費を抑えるため、ノードタイプ毎にリソースをキャッシュします。そのためEnvoyのノードタイプを設定する必要があり、ノードIDの命名規則を{node_type}-{node_id}とすることでこれを設定します。requestのために自身のクラスタ情報が必要なので、クラスタ名も指定します。このノードIDとクラスタ名は、設定ファイルに定義することも可能です。以下のように2つのサーバーが起動します。先程作成したjsonファイルをcacherサーバーに送信します。したらEnvoyに設定が反映されることが確認出来ると思います。@sidecar.jsonまとめsxdsの紹介をしていきましたが、もちろんこれも完璧ではありません。control-planeを冗長化した際は扱いづらくなるし、リソースjsonを永続化する仕組みも必要です。伝えたいことは、envoyproxyの公式ライブラリを使えば低コストでcontrol-planeを作ることが出来て、必要な機能だけ自作するという手段も十分考えられるということです。既存のサービスをマイクロサービス化する場合、必ずしもモダンな環境であるとは限りません。いった中で、環境に合わせて簡単に自作出来るという手段を持っていることは大きな武器となります。Meshをスモールスタートするという選択肢が芽生えたとしたら幸いです。Meshをスモールスタートするという選択Tweet広告を非表示にするもっと読むコメントを書く2018-10-21isucon8本戦で惨敗したからせめて良いブログを書くISUCON8の本戦に、メルカリで一緒だった@zaq1tomoと@inatonixとzin-gonicというチーム名で出場しました。結果は学生9位、全体で19位だったので、やったこととかまとめます。予選エントリはこちらです↓nakawatch.hatenablog.comやったことチューニング対象は、isucoinという取引所アプリでした。言語は予選と同じGoです。github.com担当も予選と同じです。序盤@nakabonne序盤は主にプロファイリングの準備です。ssh公開鍵登録dotfileをcloneベンチ走らせてhtopでリソース確認デプロイスクリプトの準備スロークエリログを仕込むアクセスログのプロファイルングツールalpを仕込むログローテートスクリプトを仕込むnginxのアクセスログをLTSV形式に今回はdockerでデーモン化されていたため、パフォーマンスが少し気になる上にプロファイリングが少し面倒でした。当初はdockerを剥がしてsystemdに乗せ換えようとしましたが、工数に対するインパクトが見込めず一旦後回しにしました。logsに流しており、アクセスログがうまく拾えず若干詰まりました。@zaq1tomoマニュアルとコード読んで仕様把握pprofでプロファイリング方針決め各プロファイリング結果毎に見ていきます。リソース実行時にCPU使用率は100%に張り付き、半分以上はmysqlが食っていました。メモリもギリギリで、こちらも同じく大半はmysqlのキャッシュによるものでした。この時点で早いうちにDBを外に切り出すことは決めました。スロークエリ全tradeをソートしてから取得するクエリがまず第一関門っぽかったので、初動は決まりました。二つ目もクエリ数減らせないか調査の必要がありそうだと話した気がします。見ていく必要があるのは一目瞭然で、エンドポイントが少ないことから一筋縄ではいかない匂いがプンプンでした。中盤@nakabonnemysqlを別サーバーに移行nginx基本チューニングこのクエリやばそうとかつぶやくmysqlを切り出し、サーバー1をapp+nginxのみの構成にしたためCPUに半分くらい空きが出来ました。CPUがボトルになるまではしばらくappは一台で動かそうとなりました。tradeから取得するフィールドをidのみにする修正この@zaq1tomoの修正で500点→3200点に伸びました。trade取得時にLIMITかける修正つかの間の1位この修正で5136点まで伸びました。この瞬間、我々zin-gonicは1位に躍り出ました。この時を最後に我々が笑顔になることはありませんでした。終盤@nakabonneshareボタンを有効に、、CPUに余裕が出来たところで、リソースを使い切りたいと思っていたところ、@inatonixが怪しいものを見つけました。falseどうやらシェアボタンを有効にすると取引成立時にシェアされてユーザーが流れ込み、一気に負荷があがるそうで、これだ!と有効にしました。DBサーバーを見てみるとCPUが使い切られていたので、ロックされてるのかな?と思いつつとりあえずこれはまだ早いと判断して、そっとブランチを切り替えました。講評を聞く限りここで負荷を上げても耐えられるようにすることが鍵だったらしいです。悪あがきこのブランチ量を見れば悪あがきをしていたことが分かります。何も意味をなしていません。問題作成していただいたDeNAさん、カヤックさん、主催のLINEさん、サーバー提供していただいたConoHaさん、本当にありがとうございました。今回の優勝者は学生であり、それを讃えている皆さんを見て、改めて最高の業界に来てしまったと感じました。isucon9があるならば、来年も学生枠使えるので(もはやそんな枠があるかは不明)出場したいと思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。