Github Universe 2016 で感じた事とか
Github Universe 2016ってなに?
Githubが主催するユーザーデベロッパーカンファレンスイベント
keynote
Chris Wanstrath (CEO)
- Electron をPRしてた
- Activate Power Modeにうけた
- 学生に対して無料で開放して教育への取り組みに関しての話
- 政府もOpen Sourceを取り入れているよってゆうような話
- The White House · GitHub
- このリポジトリ群初めて知った
- Projects機能の話
- Reviews機能の話
- 個人のプロフィール画面がリニューアルされてる話
Nicole Sanchez (VP)
- Free and Open to the public
- Nicole Sanchez自身の経験から、何かを学ぼうとした時に限られた人や限られた条件の中でしか情報を取得できないことはありえない事的な話
- 今後20年でコンピューターサイエンス関連の新規雇用は1500万が見込まれる。コンピューターサイエンス系の学生の今後卒業する人数からしてすでに人材不足が見込まれる
- コンピューターサイエンス系を大学で勉強していない人にも大いにチャンスがあるし、むしろ必要とされている。その為にこのキーワード(Free and Open to the public)がピッタリだなと
- 個人的にはアカデミックな学習より実践的に力が付くので良いと思ってる。独学
- 何と言っても自身が成長できる機会、学ぶ機会は人種問わずみな平等であるべきで、あとはそれを活かすかどうかはその人自身という感じはとても同意
- 退役軍人に向けたソフトウエア開発トレーニングの話もよかった
- 若い世代だけではなく学ぶ機会均等が行われてる感じが良かった
まとめ的な
自分もコンピューターサイエンスなんかやった事ないし、オープンソースの世界のおかげで今の仕事をしているし、今のプロダクトを作れているので感謝感謝と共に少しでも自分もできる寄与をしなければと思った
インターネットサービス企業の中でオープンソースの活用なしに事業をしている所はもはや存在してないんじゃないかと思う。企業として各種イベントのスポンサー、ソースの公開以外にも寄与できる事って無いかなーと思う。そのくらいお世話になってるよ。きっと。
壮大な夢と共にGithubはあるなーとkeynote見ながら思った。相変わらず英語のスピーチは苦手だけど
参考
Canary ReleaseでNginxのupgradeをした話
いち早くユーザに価値を届ける。もしくは今ユーザが抱えている課題をいち早く解決することはとても重要でこのあたりをコアバリューにしているチームも多くあると思います。
そんな流れで継続的デリバリー、デプロイあたりが注目されていて(今更感)今回はCanary Releaseでshipした話をまとめておこうと思います。
ちなみにサーバサイドアプリケーション(rubyやpythonで作られたアプリケーション)またはミドルウェア系のリリースでは話がちょっと変わってくるので注意です。
今回はタイトルの通りミドルウェアを対象にしたCanary Releaseのお話です
サーバサイドアプリケーションではシンボリックリンクを使ったデプロイ
やBlue-Green Deployment
あたりの考えも似ていて一緒に考慮すべきなのかなぁと思ってみたり。
さて本題。前提として下記のようなシステム構成で話をします
構成
構成の説明
- 基本的にAWS上にすべてを構築している
- ユーザはELBのラウンドロビンで横にスケールしたアプリケーションサーバ、その先のデータベースへアクセスしてレスポンスを取得する
- 今回はCanary Releaseについて書きたいのでシンプルな構成にしてる
- CloundwatchでELBのモニタリング
- Zabbix,mackerelでアプリケーション群の各サービス等をモニタリング
- fluent,elasticsearch,kibanaで主にアプリケーションサーバのログ系をモニタリング
実施したCanary Release
内容
- アプリケーションサーバ群のNginxのversionを上げた
主な手順
- 基本的な監視アラートを一時的にOFF。メンテ作業するのでね。
- アプリケーションサーバ群の1台のサーバをピックアップする(どれでもよい)今回は上記図の④を対象にした
- ELBからサービスアウトさせてユーザからは参照できないようにする。サービスアウトさせる方法はコンソール画面でも、APIでもどちらでも
- 上記図の④のサーバに対してnginx_buildを活用してnginxのupgradeを実施 (Chef経由で実施した)
- nginx_build便利でした! github.com
- リリース手順的なものを最初に作っていて、その手順に基づいた確認のコマンドとか打って確認する
- 良さげであれば④のサーバをELBにサービスインさせる
- ELBはランドロビンなので1/4の確率で④のサーバがアクセスを受け付けるようになる
- CloudwatchやZabbix,macherel,fluent経由のアプリケーションlogをkibanaからしばらく見てる
- このモニタリングで何か通常とは違う数値が集計されると今回の作業が何かしらの影響を与えたことになるので注意深くみる
- 問題があるようなら④のサーバにrollbackしてあげればよい
- 逆にこのモニタリングで通常どおりであると問題ないと判断ができるるので他のサーバ①~③のサーバに適用しても問題ない
注意
- 構成管理にChefを使っているのでnginx ver1とnginx ver2のレシピを流すだけ
- 冪等性は注意しとかなきゃいけない
まとめ的な感想
- 今回は既存で動いているミドルウェアのupgradeで期待値が何も変化が無い事だったので比較的楽だった
- 「テスト環境でのテストはどうしても限界あるから、とりあえず本番リリースしちゃえば」という言葉がちょっと理解できてしまった....伝わるかな....
- 障害とか不具合ってどうしたって出るもんだから出すなら意図的?最小限に抑えて出してrollbackしてデバッグした方が全体的なスピードと品質に貢献するよねってゆう話かな
staging vs test-in-production
という言葉を思い出した- ④だけを参照するELBを新たに作りELBのセキュリティポートでアクセス元を制御できればダークカナリアリリースも可能だなと思った。下記イメージ図
- 今回はDBは一つだったが別けてやってる事例も多く見かけた
- 新機能のアプリケーションのCanary Releaseとなるとまた考慮すべき点が多くありそうだな
- ELBのルーティンの課題
- 評価計測の課題
- アプリケーションでN%のユーザに利用できる機能といった感じでルーティンをする場合もあるっぽいね
- 何はともあれ実践を通して少しでも理解が深まって良かった。今後も活かしていきたいと思う
SOFT SKILLSで色々反省した
こんなツイートを見かけたので早速ポチって積読しといてやっと重い腰をあげて読んだ。 すぐに忘れてしまうので思いのままに自分なりにまとめてく
ブログ書いた。ここ5年でいちばんのおすすめ本。入社時給与交渉から引退までについて書かれてる"
— higepon (@HigeponJa) September 21, 2015
プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニアhttp://t.co/ByKMJs6FIU "
翻訳されたほんはこちら
- 作者: ジョン・ソンメズ,まつもとゆきひろ(解説),長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2016/05/20
- メディア: 単行本
- この商品を含むブログ (3件) を見る
英文はこちら
Soft Skills: The Software Developer's Life Manual
- 作者: John Z. Sonmez,Scott Hanselman,Robert C. Martin
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2014/12/29
- メディア: ペーパーバック
- この商品を含むブログを見る
全体的な感想
これもネットの書評を見たとおり、プログラマー向けのビジネス書だと思う。あとは年齢なんか結局は関係ないが、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で管理していて色々とレシピを書いていてCHEF-3694というwarningが出たのでその時に調べたことをまとめておこうと思う
CHEF-3694
下記がエラーの内容
[#CHEF-3694] Resource cloning should be removed - Opscode Open Source Ticket Tracking
今はgithubに移行していて下記あたりのissueで語られている
Chef側の対応
v12.1.0からは一応スキップできるように対応されたようです
ちなみにChef 13からは根本から対応するようす
対策
- まぁwarningなので無視する運用はあり
- 色々と工夫されてる方がいらっしゃる qiita.com
- とりあえずv12.1.0以降を使っていれば、気持ち悪いけどそのまま使えるので使ってv13が出た時にversionを上げてしまう
社内勉強会で「SRECon16の紹介」をした
基本的に毎週金曜日に30分で社内のエンジニアで勉強している。 今回は自分が発表しようと思って色々とネタを探していたが、最近参加した外部の勉強会でSREConなるものを知り、色々と追いかけてみたのでその情報を共有する内容にした。
Microservices Meetup vol.2 - Tsuyoshin blog
発表資料
SRECon
所感
- 英語がもっと得意な人は自分の数倍早く、深く理解できるだろうな....
- やっぱり各社それぞれ定義が異なっていたがそれぞれ面白かった
- failure-resilient, not failure-resistantという言葉が印象的で納得感あった
- 今回の資料には出てこないけどOn-Callという言葉も自分の中では印象的であった
- 少しでも理解が進めばよいなと
- 下記はSRE関連の情報がまとまっていてとても勉強になった
- 今後もっとSREという言葉が言われるようになると思うけど、ある程度のサービスを運営するチームであれば必然と誰かがやってる状態になって、その業務領域を皆にわかるように(ちゃんと評価されるように)
SRE
というtagがつけられた感がしてる - 下記の本を読んで見ても良いかも(スイマセン自分は読んでません)
Site Reliability Engineering: How Google Runs Production Systems
- 作者: Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy
- 出版社/メーカー: O'Reilly Media
- 発売日: 2016/03/23
- メディア: Kindle版
- この商品を含むブログを見る
Microservices Meetup vol.2
勉強会に参加させてもらったのでメモ
勉強会概要
microservices-meetup.connpass.com
発表
「マイクロサービスとSREの役割」by 鈴木@kenjiszk (株式会社FiNC)
- コンウェイの法則
- 理想形?各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 (スマートニュース株式会社)
- Freedam & Responsibility
- どの開発者もNetflixのシステムを買わせるほどのアクセス権がある
- そこでSREの作るツールが重要になる
プロダクトを作っている感覚でSREはツールを作っていく
SRE should be a Enabler , SRE should not be a Servant
SREcon16の内容とか追っていなかったのでそこでの話などとても為になった
「マイクロにしすぎた結果がこれだよ!」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トレーナーによるストレッチタイム)
- タバタトレーニング
- しんどかった。勉強会で筋肉痛になったの初めて
「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)
- 最初からHerokuを使っていてその後、Dockerへ移行
- 2002年にamazonの社長だした司令の話
Kong使ってる事例を初めてみたけど、使ってる感じどうなのかなぁ?って思ってる。ざっくり聞きたいな
最後まとめ的な
Coveを試してみた
Coveって?
要は会社のOKR、チームのOKR、個人のOKRを便利に管理するツールです。
ざっくり特徴とか
日報的に毎日進捗等を記したり、進捗N%と更新することで定量的なレポートが見えるので管理がしやすくなる。
- そのレポートをメールで飛ばされる。チームのObjectiveはチーム全員へメールされると思われる
Key Resultの部分でTO-DOSを登録できたりする
OKRのマップ(視覚化)
感想やら雑感
- 目標に対する進捗なるものの管理はすでにあったりして、もし導入するならそれを置き換えるイメージになると思う。
- 追加でこのツールも導入とか考えると、ダブル管理の部分が出てくるし、手間でしかなくなる気がする
- ちゃんと使いこなす文化ができれば、あまり関わりの無い部署のOKRの進捗が簡単にみれたりする(OKR Map)でのその点は良いと思う
- エンジニアでは無い人は使いこなせるかは、んー
- 結局ある特定の人、チームだけが使いこなしていても他の人達が分からなかったり、伝わらなければ仕事の透明性を欠き色々と問題が噴出してくるのは変わらないと思う
- 少し前にプロジェクトの見取り図なるものを教えてもらって作って運用してるけど、他部署の人への伝わってる感はそれなりに感じている