nakamura244 blog

所属団体とは関係なく、個人的なblog

社内勉強会で"HTTP/2"をざっくり理解した

毎週金曜の30分の勉強会がある。クオリティは自由でまぁテックトークをする場である。今回は自分が立候補して発表してテックトークしてきた。 その時に使った資料をupする

発表資料

speakerdeck.com

関連情報

QUIC, a multiplexed stream transport over UDP - The Chromium Projects

http://www.rfc-editor.org/rfc/rfc7540.txt

HTTP/2 and SPDY indicator - Chrome ウェブストア

感想とか

結局のところアプリケーション開発者はスクリプトのコーディングレベルでは何も気にすることはない。ブラウザは半自動的にupdateされるし、wwwサーバも運用とともにversionを上げていくのでゆるやかーにHTTP/2が普及していくのだろうなと思った。

次世代的な立ち位置のquicはすでにchromeでgoogleのサービスを使う際には既に使われてた。当たり前か

通信環境の弱いユーザに一番メリットをもたらすんではないかと思われる

HTTP/2 でNginxとH2Oのベンチマークとったらどうなんだろうかと思っている

Github Universe 2016 で感じた事とか

オープンソース

Github Universe 2016ってなに？

Githubが主催するユーザーデベロッパーカンファレンスイベント

githubuniverse.com

keynote

Chris Wanstrath (CEO)

www.youtube.com

Nicole Sanchez (VP)

www.youtube.com

  • Free and Open to the public
    • Nicole Sanchez自身の経験から、何かを学ぼうとした時に限られた人や限られた条件の中でしか情報を取得できないことはありえない事的な話
    • 今後２０年でコンピューターサイエンス関連の新規雇用は1500万が見込まれる。コンピューターサイエンス系の学生の今後卒業する人数からしてすでに人材不足が見込まれる
    • コンピューターサイエンス系を大学で勉強していない人にも大いにチャンスがあるし、むしろ必要とされている。その為にこのキーワード(Free and Open to the public)がピッタリだなと
    • 個人的にはアカデミックな学習より実践的に力が付くので良いと思ってる。独学
    • 何と言っても自身が成長できる機会、学ぶ機会は人種問わずみな平等であるべきで、あとはそれを活かすかどうかはその人自身という感じはとても同意
    • 退役軍人に向けたソフトウエア開発トレーニングの話もよかった
      • 若い世代だけではなく学ぶ機会均等が行われてる感じが良かった

まとめ的な

自分もコンピューターサイエンスなんかやった事ないし、オープンソースの世界のおかげで今の仕事をしているし、今のプロダクトを作れているので感謝感謝と共に少しでも自分もできる寄与をしなければと思った

インターネットサービス企業の中でオープンソースの活用なしに事業をしている所はもはや存在してないんじゃないかと思う。企業として各種イベントのスポンサー、ソースの公開以外にも寄与できる事って無いかなーと思う。そのくらいお世話になってるよ。きっと。

壮大な夢と共にGithubはあるなーとkeynote見ながら思った。相変わらず英語のスピーチは苦手だけど

参考

github.com

Canary ReleaseでNginxのupgradeをした話

Infrastructure Chef カナリアリリース

いち早くユーザに価値を届ける。もしくは今ユーザが抱えている課題をいち早く解決することはとても重要でこのあたりをコアバリューにしているチームも多くあると思います。

そんな流れで継続的デリバリー、デプロイあたりが注目されていて（今更感）今回はCanary Releaseでshipした話をまとめておこうと思います。

ちなみにサーバサイドアプリケーション(rubyやpythonで作られたアプリケーション)またはミドルウェア系のリリースでは話がちょっと変わってくるので注意です。

今回はタイトルの通りミドルウェアを対象にしたCanary Releaseのお話です

サーバサイドアプリケーションではシンボリックリンクを使ったデプロイやBlue-Green Deploymentあたりの考えも似ていて一緒に考慮すべきなのかなぁと思ってみたり。

さて本題。前提として下記のようなシステム構成で話をします

構成

f:id:tsuyoshi_nakamura:20160916212221p:plain

構成の説明

実施したCanary Release

内容

主な手順

  1. 基本的な監視アラートを一時的にOFF。メンテ作業するのでね。
  2. アプリケーションサーバ群の1台のサーバをピックアップする（どれでもよい）今回は上記図の④を対象にした
  3. ELBからサービスアウトさせてユーザからは参照できないようにする。サービスアウトさせる方法はコンソール画面でも、APIでもどちらでも
  4. 上記図の④のサーバに対してnginx_buildを活用してnginxのupgradeを実施 (Chef経由で実施した)
  5. リリース手順的なものを最初に作っていて、その手順に基づいた確認のコマンドとか打って確認する
  6. 良さげであれば④のサーバをELBにサービスインさせる
  7. ELBはランドロビンなので1/4の確率で④のサーバがアクセスを受け付けるようになる
  8. CloudwatchやZabbix,macherel,fluent経由のアプリケーションlogをkibanaからしばらく見てる
  9. このモニタリングで何か通常とは違う数値が集計されると今回の作業が何かしらの影響を与えたことになるので注意深くみる
    1. 問題があるようなら④のサーバにrollbackしてあげればよい
  10. 逆にこのモニタリングで通常どおりであると問題ないと判断ができるるので他のサーバ①~③のサーバに適用しても問題ない

注意

  • 構成管理にChefを使っているのでnginx ver1とnginx ver2のレシピを流すだけ
    • 冪等性は注意しとかなきゃいけない

まとめ的な感想

  • 今回は既存で動いているミドルウェアのupgradeで期待値が何も変化が無い事だったので比較的楽だった
  • 「テスト環境でのテストはどうしても限界あるから、とりあえず本番リリースしちゃえば」という言葉がちょっと理解できてしまった....伝わるかな....
    • 障害とか不具合ってどうしたって出るもんだから出すなら意図的？最小限に抑えて出してrollbackしてデバッグした方が全体的なスピードと品質に貢献するよねってゆう話かな
  • staging vs test-in-productionという言葉を思い出した
  • ④だけを参照するELBを新たに作りELBのセキュリティポートでアクセス元を制御できればダークカナリアリリースも可能だなと思った。下記イメージ図 f:id:tsuyoshi_nakamura:20160920093347p:plain
  • 今回はDBは一つだったが別けてやってる事例も多く見かけた
  • 新機能のアプリケーションのCanary Releaseとなるとまた考慮すべき点が多くありそうだな
    • ELBのルーティンの課題
    • 評価計測の課題
    • アプリケーションでN%のユーザに利用できる機能といった感じでルーティンをする場合もあるっぽいね
  • 何はともあれ実践を通して少しでも理解が深まって良かった。今後も活かしていきたいと思う

SOFT SKILLSで色々反省した

本

こんなツイートを見かけたので早速ポチって積読しといてやっと重い腰をあげて読んだ。 すぐに忘れてしまうので思いのままに自分なりにまとめてく

翻訳されたほんはこちら

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

英文はこちら

Soft Skills: The Software Developer's Life Manual

Soft Skills: The Software Developer's Life Manual

全体的な感想

これもネットの書評を見たとおり、プログラマー向けのビジネス書だと思う。あとは年齢なんか結局は関係ないが、20代のうちに読んでおきたかったなーと感じた

特に刺さった部分をpick up

第4章 社交術:考えているもの以上のものが必要だ

人間は非常に感情的な生き物

正しい理論を訴えてもその人との関係値があまりイイものではなければ無駄に批判されたり、思いもよらない方向へ進んでしまうので日頃の些細な関係値づくりは必要という話。ただ世の中にはどんなにこちらが頑張っても批判ばかり口にする人がいる。もしそんな人に出会ってしまったらその人に気づかせてあげよう・うまく付き合っていこうなんて思わない事だと言っている。人の人間性を変える事はそんなに簡単な事ではない。自分の為にできるだけ逃げる事も重要だと。もし直属の上司だったら移動願い、無理だったら迷わず転職を勧めていた

第10章 プロであること

正しい事をする

ソフトウェア開発者で著作家のボブ・マーティンの説明で医者を例にして説明している

患者が医者の仕事の仕方に指示をする事がバカげているのはだれでも納得できるだろうと

患者が腕がひどく痛むので切り落としてしまってくれと医者に指示しても医者は絶対「No」というしそれが正しい判断だと

でもソフトウェア開発に話を戻すと、患者と同じ立場であるクライアントや上司に断片的な情報を元にまぁいいからこの仕様で作ってくれと言われてそのまま従ってしまう技術者が多いと。怒りをかってしまうのではないか、失注してしまうのでは無いかという恐怖がある。でもプロには超えてはいけない一線があってそこは守るべきだと。当然その場では何かしらの代償を払う可能性はあるが、長いプログラマー人生を考えたときはそちらのが良いと

第18章 テクノロジーに対して頑なな態度をとるな

選択肢を制限しない

自分が選択したテクノロジーが最高だと強調して、他のすべてのテクノロジーを過小評価してはならぬ。それは最終的に自分を傷つける事になる

自分があまり良いと思っていないテクノロジーを選んで、そのテクノロジーが良いと思ってる人を探して理由なり聴いて理解に努めよう

第26章 バカにされるのを恐れるな

小さなステップを踏もう（でなければ飛び込め）

批判される事はある程度覚悟しながらも恐れずにアウトプットし続ける。恐れて何もしていない事こそ自分にとっては最も恐ろしい事だと。小さな事でもいい最初は。でもそれすらできなければ...一気に飛び込んで必死にもがいたらイイ

このくらい刺激的な言葉だと覚えやすい!!

第28章 私の10のステッププロセス

「学習 - 実践 - 学習 - 教え」(LDLT, learn-do-learn-teach)

より理解が深まり、且つチームのレベルも押し上げる

第35章 知識の中の隙間を見つける

ただ何となくでしか理解していない事やあやふやな理解のままで事が進んでいくと弱点が長期的に増えてくる

そういった隙間が多くなると効率を最大限に引き上げて仕事をすることができなくなる

メモパットを身近において、隙間を定量的に貯めていく事から始める

第45章 習慣を作る:コードを磨こう

悪い習慣に気づいて変える

新しい習慣を生み出す

自分にxxをしなければ自分にとって重要なxxができない状況・決めを作って最初はしんどいけど頑張るしかない

第48章 どんなことでも、しないよりした方がまし

動かないでいる最大の理由は恐怖

行動を取らないでいるのは駐車している車のハンドルを切るのと同じで簡単にはきれない

逆に動いている車のハンドルは切りやすい

誰でも無駄な事は避けたいし、目的に向かって一直線で進みたいと思っているけど、実は動きながら考えて色々とハンドルを切って方向転換しながら進むことは走行距離は増えるけど最短の時間で到達できるという話

第65章 心は身体にどのようにして影響を与えるか

すべては心から始まる

信念が変われば、思考も変わる

思考が変われば、言葉も変わる

言葉が変われば、行動も変わる

行動が変われば、習慣が変わる

習慣が変われば、人格も変わる

人格が変われば、運命も変わる

宗教臭い感じもするけど納得している

第70章 失敗に正面からぶつかれ

失敗と敗北は同じではなく、失敗は一時的で敗北はずっと続く。敗北は自らの意思で選んだ結果

でもなるべく失敗してもダメージが少ない場面を選ぶとより良いと思ってる

最後に

  • 多少できてる部分もあればまだまだと感じた部分もあった
  • 元々エンジニアだった人が書いたビジネス書のようなものなので言っている内容がスッと入ってくる
    • 元々エンジニアの人が言ってるから妙な説得力がある
  • アメリカのソフトウェア開発を元に書いているので日本でもそのままとはいかないと思うけど本質的な部分はまぁそうですよねという感じ
  • 老害にならないように低姿勢に真摯に自分を見つめ直す時間を持てて良かった
  • 色々と突っ込みたい事はあったりするんだが、この本で出てくる第4章の内容を胸に読み込んだ

chefのCHEF-3694課題をちょっと追いかけたのでメモる

Chef Infrastructure

インフラ関連はChefで管理していて色々とレシピを書いていてCHEF-3694というwarningが出たのでその時に調べたことをまとめておこうと思う

CHEF-3694

下記がエラーの内容

[#CHEF-3694] Resource cloning should be removed - Opscode Open Source Ticket Tracking

今はgithubに移行していて下記あたりのissueで語られている

github.com

github.com

Chef側の対応

github.com

v12.1.0からは一応スキップできるように対応されたようです

ちなみにChef 13からは根本から対応するようす

github.com

対策

  • まぁwarningなので無視する運用はあり
  • 色々と工夫されてる方がいらっしゃる qiita.com
  • とりあえずv12.1.0以降を使っていれば、気持ち悪いけどそのまま使えるので使ってv13が出た時にversionを上げてしまう

社内勉強会で「SRECon16の紹介」をした

勉強会 SRE

基本的に毎週金曜日に30分で社内のエンジニアで勉強している。 今回は自分が発表しようと思って色々とネタを探していたが、最近参加した外部の勉強会でSREConなるものを知り、色々と追いかけてみたのでその情報を共有する内容にした。

Microservices Meetup vol.2 - Tsuyoshin blog

発表資料

speakerdeck.com

SRECon

SREcon16 | USENIX

所感

  • 英語がもっと得意な人は自分の数倍早く、深く理解できるだろうな....
  • やっぱり各社それぞれ定義が異なっていたがそれぞれ面白かった
  • failure-resilient, not failure-resistantという言葉が印象的で納得感あった
  • 今回の資料には出てこないけどOn-Callという言葉も自分の中では印象的であった
  • 少しでも理解が進めばよいなと
  • 下記はSRE関連の情報がまとまっていてとても勉強になった
  • 今後もっとSREという言葉が言われるようになると思うけど、ある程度のサービスを運営するチームであれば必然と誰かがやってる状態になって、その業務領域を皆にわかるように（ちゃんと評価されるように）SREというtagがつけられた感がしてる
  • 下記の本を読んで見ても良いかも（スイマセン自分は読んでません）
    Site Reliability Engineering: How Google Runs Production Systems

    Site Reliability Engineering: How Google Runs Production Systems

Microservices Meetup vol.2

勉強会

勉強会に参加させてもらったのでメモ

勉強会概要

microservices-meetup.connpass.com

発表

「マイクロサービスとSREの役割」by 鈴木@kenjiszk (株式会社FiNC)

speakerdeck.com

  • コンウェイの法則
  • 理想形？各microsericeのチームにSREをいれるのがよい？
    • SREのリソースがネックになりつつある
  • SRE業務ができる人材を育てる。権限の委譲を進めながら
  • 開発/SREの壁をどんどんとり払っていく
  • SREももちろんコードを書く
  • SREが責任を持って守るライン
    • セキュリティ
    • コスト管理
    • スケール
    • 新技術の取り組み

マイクロサービスの本やInfrastructure as Codeの話等々を踏まえて自分は、セキュリティは独立したチームを組むべきで、逆にそれ以外は各microservicesのチームに託していくべきだと思っている。

SRE（の役割）とは各microservicesのチームに含まれている部分もあれば、独立して担う役割の部分があると思ってる。当然各チームや会社によって範囲は変わってくる。

なのでマイクロサービスとSREというのはそれぞれの解釈？定義が違うので一概に語ることは難しく、FiNCさんの場合はという感じで聞いていた。

参考

マクロサービスアーキテクチャを数回読んだ - tsyoshin blog

Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に参加してきた - tsyoshin blog

「SRECon 2016 Wrap Up」by 坂本さん@takus (スマートニュース株式会社)

speakerdeck.com

  • Freedam & Responsibility
    • どの開発者もNetflixのシステムを買わせるほどのアクセス権がある
    • そこでSREの作るツールが重要になる

  • プロダクトを作っている感覚でSREはツールを作っていく

  • SRE should be a Enabler , SRE should not be a Servant

SREcon16の内容とか追っていなかったのでそこでの話などとても為になった

SREcon16 | USENIX

「マイクロにしすぎた結果がこれだよ！」by 榎本さん@mosa_siru (株式会社Gunosy)

www.slideshare.net

  • AWSのsecurityグループとIAMを活用して経路自体に制限をかけてまとめた
  • 全体構成が複雑が複雑になり人数いないと機能しない話
  • 少人数のために各APIを管理する統合管理画面なるものを作成してその為だけのAPIを作った話
    • ここまでくるとちょっと辛いし、microsericeは自立したチームでもあるので、組織構成が大切だなと

「Microservicesの実際と対策」by 大谷さん@shot6 (株式会社 ファーストリテイリング)

  • swagger使ってる
  • appはnodeで書くパターンが多い
  • kong使ってる
  • 体制が重要で。専任のスモールチームが必要
  • そもそもマイクロサービスとは、すごく優秀な数名で最大限に活用するモデルがmicroservice
  • 課題
    • 運用面。既存の仕組みとの連携方法が難しい
    • 共通的に解決しなくてはいけない課題をどう乗り越えるか？
    • 答えがないのでどうやって横のつながりを増やすか
    • サービス間の通信の可視化
    • 依存関係の把握
    • microserviceのテストの課題。dockerにすりゃ済む話ではない。10個以上docker立ち上げられないよローカルで

ウェルネスタイム (大好評、FiNCトレーナーによるストレッチタイム)

  • タバタトレーニング

tabata-protocol-training.com

  • しんどかった。勉強会で筋肉痛になったの初めて

「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)

speakerdeck.com

元ネタは綺麗なAPI速習会 - Qiita

  • 最初からHerokuを使っていてその後、Dockerへ移行
  • 2002年にamazonの社長だした司令の話

Kong使ってる事例を初めてみたけど、使ってる感じどうなのかなぁ？って思ってる。ざっくり聞きたいな

最後まとめ的な

  • Microservicesは取り入れる取り入れないの判断がむずかしいなぁ。
  • これは無条件でやるべしという感じでは無く、選択にミスると痛い目あう
    • しかもその影響が割と経営とかにインパクトしてしまうぐらい大きいのでしっかり見極めないと
  • 失敗した話だったり、現場感あってあまり聞ける話では無いので良かった
  • あまり答えが無い中で皆さん苦戦している様子だった
  • SREという本来的な役割は賛成だし、実践していくべきだと思うけど、成果の見える化？経営層へのアピールは中々むずいだろうなと感じてしまった
  • インフラという言葉は今後なくなっていくのだろうか...