はぜにっき

日記です。(毎日更新ではない)

ポートフォリオサイトをAWS Amplifyに移した

dev.classmethod.jp

この前のre:Invent 2018でAWS Amplify Consoleっていうのが発表されて、丁度使う機会があったので使ってみたよ。

以前

GCPの無料枠を使って、g1-small のCompute Engineにnginxを入れて、ソースコードを中に投げて運用してました。
で、deployは 手元で npm run build して、生成された /build ディレクトリをsshでぶん投げる っていうのを雑にスクリプト書いて叩いてやってました。

まあ、それもそれで面倒なのでどこかのタイミングでgithubにpushしたら良い感じにデプロイしてくれるように仕組みを作ろうかなーと思っていたところ。

f:id:hazeblog:20181220224347p:plain:w300
あと51日で無料枠も消滅するので丁度良かった

AWS Amplify Console やるぞ

そもそもAWS Amplifyっていう静的サイトのホスティングサービスがAWSにはあって、それにいろいろ機能が付きましたよっていうのが、re:Inventで発表された内容。
その追加機能の中に、GitHub/GitLab等にpushすると勝手にデプロイしてくれるCD機能があったので、それを使っていこうという感じです。

github.com

今回デプロイするリポジトリはこれ。

手順

AWS コンソール画面のサービス一覧から AWS Amplify を選んで作成を押すと、トリガ/ソースコード元となる連携先を選ぶ画面になる

f:id:hazeblog:20181220225038p:plain:w300
BitBucketもあるよ

で、認証したらリポジトリとブランチを選んで

f:id:hazeblog:20181220225233p:plain:w400
master以外も設定できる、便利

buildの設定(create-react-appで作ってたらそのままでおっけーっぽい)をして、環境変数を設定して、

f:id:hazeblog:20181220225349p:plain:w400
確認画面

ポチッと押すと、

[f:id:hazeblog:20181220225427p:plain:w400
でぷろい開始

デプロイがはじまる。

で、うまく行ったら、デプロイ先のURLリンクが出てくるからそれを押せば、デプロイされたページが出てくる。

便利じゃん。。。

f:id:hazeblog:20181220225648p:plain:w300
ビルドがこけるとこうなります


ドメインはお名前.comで取っていたんですが、お名前.com側でDNSネームサーバをRoute53に向けて、Amplify側でドメインを設定すればおっけーでした。

お名前.com <-> Route53 の部分はこのエントリを参考にした。わかりやすい。

tech.tanaka733.net

上記エントリに従ってRoute53側でドメイン設定ができていれば、Amplify Consoleの「ドメイン設定」で連携が一瞬でできます。便利。

f:id:hazeblog:20181220230447p:plain
ドメイン設定画面


というわけで https://haze-page.tokyoAWS Amplifyに移したログでした。
サーバレスだしCompute Engineよりは安いやろ!という勘で移行したんですが実際毎月いくらぐらいの請求になるんでしょうね。

ところで、東京リージョンがまだ対応してなくてオハイオリージョンでやっているので結構遅いです。画像も小さくしてないから更に描画が遅い。。。
ちゃんとWebサービス作ってその上に乗っけるんだったらCDN必須っぽいですね。そういうのも今後やっていきたいです。

ストレングス・ファインダー2.0 受けた

この本を読んで、ウェブテストを受けた。

本には、「不得意なことにたくさんの 時間をかけて克服するよりも、得意なこと・才能があることに時間をかけて特化しよう」といった内容が書いてある。
自分は学生の頃、英語や漢字の暗記がとても苦手で、試験期間中ずっとその勉強をしても平均の点数さえ取れなくて諦めた覚えがあり、耳が痛くなった。
まあ今は知っている中で一番得意であろう分野で仕事をしているので良いと思う。他の仕事できる気しないし。


このウェブテストは、性格診断っぽい質問を答えると自分の「強み」がわかるというテストで、弊社のマネージャ研修などでも活用されている。
かなりの実績があるっぽく、参考程度になるかなと思ってやってみた。

f:id:hazeblog:20181209124107p:plain
結果

納得感がある。

テストを受けると、「強みの理解レポート」と「自分だけの特徴的な資質レポート」が出力される。

「強みの理解レポート」を一部抜粋。(引用の枠を超えているんだけど、自分用のレポートだから良いよね...?)

強みの理解レポート

学習欲

「学習欲」の資質が高い人は、学習意欲が旺盛で、常に向上を望んでいます。結果よりも学習すること自体に意義を見出します。
あなたは本能的に、 自分の研究や仕事関連の任務で優れた能力を発揮するために必要であれば、どんなことでもすることがあります。 これが、あなたのやる気をそぐような人がいるチームよりも、一人で課題に取り組むことを好む理由の1つなのでしょう。
おそらくあなたは、 あれこれと考えを巡らせたり、興味深い話題について読んで検討したりする静かな時間を好みます。 あなたは、邪魔されずに思考できる時間が得られると、大きな喜びを感じます。 あなたは、自分のアイデアを徹底的に検証するため、騒がしく、気ぜわしい、集中できない状況から逃れようとするはずです。
多くの場合、あなたは、 ときどき、難易度が高かったり、課題の多かったりする講座に登録することがあります。 特定の物事について自分の知識を広げたり考えを試したりしたいのでしょう。

今回の転職理由がそのまま書いてあって笑った。

"必要であれば、どんなことでもすることがあります。"
この前書いていたエントリのお話ですね。

内省

「内省」の資質が高い人は、知的な活動に多くの時間を費やします。内省的で、知的な議論が好きです。
おそらくあなたは、 1人で思索にふける時間を切に求めています。 自分の知的好奇心をかき立てるものなら何についても考えます。
毎週時間を取って自分のアイデアを追求することは、喜びであるばかりか必要な活動でもあります。
あなたは、沈黙が長く続くと心から安心感を覚えます。 なぜなら、 沈黙のおかげであなたや他の人たちは、歴史の流れや人々の生活を変えるような理論を検討したり、何かを発案したりできるからです。
あなたは、 さまざまなアイデア、理論、または概念について疑問を呈する傾向があります。
あなたは普段、結論を出したり、新しいアイデアを提示したり、状況を違う観点から見たり、詳細な質問をしたりする前に、よく考えを巡らします。
多くの場合、あなたは、 自分の本質や自分の存在理由に関する質問と戦っています。

学習欲に近しい部分が多い。
基本的に出社せず家でリモートワークしているのは、一人で居られる時間が多いってのも理由の一つだったりする。
オフィスに行っても端っこのソファに座ってもくもくしているのも同じ理由。
雑談が嫌いなわけじゃないんだけどね

自我

「自我」の資質が高い人は、大きな影響を与えることを望んでいます。独立心に富み、組織や周囲の人々に与える影響の大きさに基づいてプロジェクトに優先順位をつけます。 多くの場合、あなたは、 ときどき、個人的なまたは仕事上の特定の目標を達成するためにがんばります。 これには、昇給、昇進、学位の取得、あなたが価値を置くものの取得、または認証プログラムの完了などが含まれますが、これに限るものではありません。 あなたは本能的に、 個人プレーヤーであり、自分が達成したものを人々に確認してもらうことで、彼らに影響力を行使します。 あなたは、 仕事を自分の私生活の中に切れ目なく織り込みたいと思っています。 この2つを線引きして分けることはしません。 おそらくあなたは、 いつも、さまざまな専門上の問題に対処するために必要な強みを持つことを認められたいと考えています。 他の人にあなたが重要人物であると見られたいため、わかりづらい情報をマスターしたり、高度に特化した能力を獲得したりしようという気になるようです。

承認欲求ですね。

目標志向

「目標志向」の資質が高い人は、目標を定め、その目標に向かってまい進し、目標達成に必要な修正を行うことができます。優先順位をつけてから、そのとおりに行動します。
おそらくあなたは、 自分が達成すべき物事を的確に把握します。 そしてそれに専心します。
多くの場合、あなたは、 一人で仕事することを選ぶことがあります。 そうすれば、あなたがこれからの数週間、数か月、数年、数十年に実現したいことを綿密に計画することがずっと容易にできるかもしれません。
必要であれば、会話を実際的または事実的なものに戻す役割を担うこともあります。
あなたは、 自分自身の週間パフォーマンス目標を設定することに真剣に取り組むことがあります。
あなたは、 時折、事実を強調し、他の人に真実の方向性を示すことがあります。 あなたはだまされやすい人の目を覚ますようです。
事実に基づくあなたのスタイルの手助けで、他の人は共通の基盤を見いだすのかもしれません。 完全に同意に至るようなコンセンサスが得られることがあるかもしれません。

ずっと悩んでいるのは、何を持って"事実"と認識するかどうか。最近ここが雑になっていて、事実ではないことを事実と思い込むことがある。
仮説検証の能力をつけると、もっとうまくできるのかなーって思ったりしている。

"多くの場合、あなたは、 一人で仕事することを選ぶことがあります。"
自分のコントロール権限がある仕事をしたいっていう話かな

未来志向

おそらくあなたは、 ときどき、今後数週間、数か月間、数年間、数十年間で達成できることを考えることがあります。
改善できることを考えるだけで、あなたが特定の仕事で成果を上げる原動力になります。
あなたは本能的に、 これからの数週間、数か月、数年、数十年に、世界や自分自身をどのようにしたいのか心に思い描くことがあります。生まれながらにして、あなたは、 今後数週間、数か月間、数年間または数十年間に到達可能なことに関して革新的な構想を練るために、自然と多くの時間をかけます。 あなたは、専門分野に集中しているとき、発明家、空想家、夢想家としての行動を見せることがよくあります。
あなたは、 今後数週間、数か月間、数年間、数十年間の内に、よりよくできることについて想像することがあります。 あなたには、改善したり、改良したり、また完成させたりできる事柄が、鮮明に見えているでしょう。
またあなたは、環境や自分自身、周りの人、システム、プロジェクト等において、変える必要のある点についても判断することができます。
多くの場合、あなたは、 自分の選んだ将来を形作ることにたっぷり時間を取ります。 そして頻繁に、今後数か月、数年、数十年で可能性のあることに関する自分のアイデアを共有します。 おそらくは、自分のイメージした生き生きとした詳細をあなたが語ると他の人の注意を捉えるのでしょう。

スタートアップっぽい感じのことがたくさん書いてある。
ビジョン・ミッションを明確に定めている環境に行きたかったので、そうだなあ、と思いながら読んだ。


全体的に納得感がある。というか自分本位なのがよくわかる。
同時に、やっていることがそこまで間違ってなさそうという安心感が出てよかった。
今後もしばらくはスタートアップ企業でエンジニアを続けていくんだろうな、と思いました。

本を読んでいると "大学院などに興味を持つでしょう" って書いてあって、去年大学院行こうと思って色々調べてたり、今は仕事しながらでも行ける通信制の大学に出願しているので良く当たるもんだなあと驚いたり。

書籍にも書いてあるけど、世の中には様々な考え方をしている人がいて、それぞれのパターンをある程度知ることで仕事でのコミュニケーションを円滑に進めて行ける可能性が高くなるので、やったことがない人はやってみると良いと思う。
@haze_it_ac はこういう考えなので だいぶ面倒な人間だと思いますが、今後もよろしくです。(?)

23歳になりました

なりました。めでたい。

20歳を超えてからは嬉しい気持ちは無くなりました。めでたいって言いましたが特にめでたくもないですね...
今日は有給取って1日中寝てやろうかと思ったんですが、入社時にもらった有給は試用期間中に入院して消滅していたんでした。普通に仕事です。


22歳は何していたかというと、前職でChefをいじったりチャットボットを作ったりして、今の会社に転職して、APMを調べて、RailsとReactを触り始めていました。
今回(?)はどうなるんでしょうか。正直もう転職と引っ越しは面倒だからやりたくない。

新卒(20歳)のころは5年後こうなっていたいとか、10年後はこういう立場になっていたい みたいなことを考えていたんですが、今は1年後すら想像ができないです。5年後なんてもう。
今。何がしたいかみたいなところはある程度わかるんだけど、1年後にそれを達成していたら次はどういうことをしたくなるかが全くわからないですね。

で、今後自分はどうなっていきたいんだろう っていうのを考えるために、自分が大切にしている考え方みたいなものを最近は考えていたんですが( 市場価値と自分の技術に対する興味 / 「一番下手くそでいよう」のつらさ )、うまくあらわせないし、割と短期的な目線でしか物事考えてないっぽいし、今後に繋がるわけでもなかった。
その代わりに、自分の気持ちとか、その時々の感情には正直に向き合えるようになってきた気がします。悪く言えばわがままになったんですが、それでも良いでしょう。

このエントリも本当は "今年を振り返って〜〜" みたいな感じでゆるく総括するつもりだったんですが、発散しまくりで無理でした。
あと1年ぐらいは色々考え込んだり方向転換しても許されるんじゃないかと思ってます。パートナーもいないし(?)。

もう暫くはこんな感じでふわふわ生きていると思います。23歳のはぜもよろしくお願いします。

例のリスト


iRobot Roomba 890 買った

11月末に890だけがビックカメラで30,000円引きになっていて、よくみたらポイントが余っていて、気付いたらポチっていた。

写真の通り、これまでは eufy という、Anker製のちょっと安いロボット掃除機を使っていました。

これはこれで安いしちゃんと仕事してくれるしちょっと小さいので一人暮らしには丁度良いんだけど、7月に1LDKに引っ越したタイミングで取り残しが発生するようになってしまった。
ので、適当なタイミングでグレードをあげようかな(上位互換としてeufy 20というものがあります)と思っていたんだけど、まさかルンバのWiFi対応モデルがここまでやすくなるとは。。。。

まだ一回しか走らせていないけど、力強い動きをしてくれていて安心感がある。
その代わり、ちゃんと固定できていない家具(軽い椅子とか)がぶつかって少し動いてしまうけれど、それはまあ仕方ない。

www.irobot-jp.com

ルンバにはバーチャルウォールという機能があって、どういうものかというと、デュアルバーチャルウォールという付属品を適当な場所に置くと、その周りだけは立ち入らないようになってくれる。
はぜハウスでは衣類乾燥機があって、その下に排水用のバケツとか2Lペットボトルを置いていて、それを倒されると大惨事なのでこれが重宝する。
これまでeufyを使っている時は、掃除させる前に避難させていてちょっと手間だったんだけど、バーチャルウォールを使うことで避難しなくてもよくなり、最高。

というわけで良い買い物っぽい。長持ちさせたい。
お古になったeufyはクリスマスイブに男友達にあげる予定。はぜサンタです。よろしくお願いします。

「設計について語る会」参加してきた

なにこれ

若めのエンジニアこみゅにてぃで「設計よくわからんのだが」みたいなことを話していたときに、 ダンボー田中さんが提案・開催してくれたので参加してきたレポ。

主催側の経緯や、話の流れについてはダンボーさんのエントリを参照してくださいな。

tanakalivesinsendai.hatenablog.com

会場はLINE株式会社セミナールームでした。 nasa9084 さんありがとう。

f:id:hazeblog:20181201230435j:plain:w300

げすと

ダンボー田中さんと一緒にiOS設計パターン本を書いたtakasekさんも参加してくれた。
各種アーキテクチャパターンについてのわかりやすい解説をしてくれたり、議事録をまとめてくれたり、最高でした。ありがとうございました :bow:

iOS設計本についてはダンボーさんからもオススメされたのでしばらく前に買った。年末に時間あるのでゆっくり読みたい。

f:id:hazeblog:20181031112028p:plain:w500

流れ

  • 自己紹介
  • ダンボー田中氏による基調講演: 設計とは?
  • 議論

自己紹介

参加者は9人ぐらい。

属性は iOS / BackEnd / FrontEnd / Infra? といった感じでした。

議論内容と個人用メモ

ほわいとぼーど

f:id:hazeblog:20181201235901p:plain:w600

f:id:hazeblog:20181202000444j:plain:w600

f:id:hazeblog:20181202000517j:plain:w600

f:id:hazeblog:20181202000545j:plain:w600

以下メモ

フレームワークに依存するお話

  • 手を抜くためにフレームワークを使う

  • Rails/Laravelと心中する?

  • 主にGo界隈で生SQLを書く、OR Mapperを使わないでモノを作るという話が出てきたりする

秩序を保ち続けるのは難しい

  • 「強いエンジニア」しかいなければ秩序は保たれる
  • 人の話になるけど、どう秩序を担保していくか、コントロールしていくかは重要

  • 理解が弱い人でも正しく使えば正しい設計になる、ということを期待してフレームワークを使うこともある

人への依存について

  • 組織のスケールを考慮から外せば、「レビュー」の仕組みで良い
  • レビューする人がいなくなる、のは組織が死んでいることを表している。秩序が無くなる=そういうこと

  • ドキュメント化とレビューのタイミング: 後述

設計に関する共通認識が必要という話

うすうす感じてはいたけど、人が「MVC」と言うときに同じことを指しているというわけではない。
言語化する時点である程度はそうなるんだけど、同一のイデアを持てていないよね、っていう話がある。

MVCに限らず、〜〜アーキテクチャは全てそうなりがちだと思うし、色んな文脈で語られるDDDとかClean Architectureとかも多分共通認識が取れているかと言われるとそうでもないと思う。
(勿論正しく認識を取れている人が一定数いることは知っているんだけど、全員がそうではないよねっていう文脈です)

その共通認識を持つための議論は定期的に組織内でしたほうが良いだろうし、
新しい概念を社内で共有するより「現状触っている物事の言葉やプロダクトの設計について共通の認識を持つことのほうが重要なのでは?」と思ったりした。

MV* の話

speakerdeck.com

takasek先生がまとめてくれているスライドがある :bow:

アーキテクチャの分類

大きく分けて2つある
(上のスライドの5枚目)

  • GUI Architecture
    • MVC, MVP, MVVM, etc...
    • UIにどう関係するかどうか を基準に機能を分けている
  • System Architecture
    • Hexagonal Architecture, Onion Architecture, Clean Architecture
    • UIの部分だけでなく、Model部分の分類をしようとして概念が作られている

MVVM

  • (正しい) MVCのControllerとViewのロジック部分以外を合わせてViewと表現
  • ViewのロジックをViewModelとして切り出し

アーキテクチャの理解って本読んだりエントリ読んだりするだけだと理解できないよねという話

https://www.amazon.co.jp/dp/B00ZQZ8JNE/www.amazon.co.jp

DDDとかの概念をC#で丁寧に説明してくれている本とのこと

www.slideshare.net

Goにおけるレイヤ構造の実装の話

booth.pm

およびその本(買った)(積本が増えていく)

takasekさんにアーキテクチャをどうやって理解するの?って聞くと、本読んだ上で自分で実装している、とのこと。

名前付型付けと構造的型付けの話

聞いていて本当にさっぱりだった。

qiita.com

otiai10.hatenablog.com

Goにおけるインタフェースは、他言語のインタフェースとは定義が逆で、
他言語(Javaとか)は、データ側に設定されているけど、Goだと持ってくる側が形を指定する、とのこと、

型でなんとかなる部分と、そうでない話

「ID」が複数同じような形式であると型を定義していても取り違う可能性があるよね
( user_id: 12345678 , terminal_id: 11335588 みたいな)

ドキュメント化とレビューのタイミングについての考察

レビューをする前の認識合わせが必要 という話をした。
コードを書く前に、どういうものを作るか、何を検討した上で、どういう設計にするのか、についてチームと合意をとる必要がある。
=> Design Doc

弊社事例

この辺の話は開発者ブログとかで紹介したほうが良いような気がしたけど、とりあえずここに書く。
(※この発言や説明や解釈は会社としてのアレではなく個人のどうのこうの)

Kaizen Platformでは、機能を開発するとき、改修するとき、何かしらある程度設計や動作確認テストを必要とするコード変更を伴う場合、Design Docというドキュメントをコードを書く前に書きます。

機能開発の流れを説明すると、
まず、Product Managerとか担当Engineerが、「どんなものを作るか、何を達成するためのものか」を明文化・定義するためのPRD(Product Requirements Document)を書く。
その次に、前述したDesign Docを書く。
そして、PRDとDesign Docをもとに、内容をPM+Engineer(+レビューEngineer)で確認して、OKだったらやっとコードを書き始める。

product issue(要望)
 ↓
PRD (製品仕様書、要求定義と必要条件)
 ↓
Design Doc (設計書、動作確認内容と考慮点)
 ↓
ソースコード

これらは開発時に使われる他、「どんな理由でこの機能を作ったか?」を示すログの役割を持っていて、Qiita::Teamにタグをつけて保管されています。
(ログ以外の役割として、リモートワークをする上での共通認識を作るため、および暗黙知を無くすためなどがあります)

当然、PRDやDesign Docに沿って正しく実装されたかは、レビューとQA(動作確認)で確認します。

「今のシステムを説明するためのドキュメント」

"Design Docを更新するか否か?” という話があり、何のために書くか、という話に落ち着く。
自分は更新すべきではない(前述した通りログ、Historyの意味合いを持つので)と思っている。

現状の仕様を確認する際に、機能ごとに分けられたDesign Docをさらい続けるのは正直きつくて、「今の仕様を表すドキュメント」が他に必要になる。

それの場所って、どこが良いの?という議論が最後のほうであって、とても考えさせられた。

GItHubリポジトリのREADME.md

リポジトリに閉じた話はこれでやるのが一番良さげで、HistoryもGitで管理ができるし、ソースコードと同じ場所にあるから参照がしやすい、また更新されやすい。
ただし、複数リポジトリに跨った仕様はどうするか?という話があって、意見がわかれそうなところ。
個人的には別途Issueとか複数リポジトリにまたがったドキュメントを管理する用のリポジトリを別途作っておいて、そこにサービス全体としての仕様を書いたりすると、なんか良いんじゃないかなと思う。管理大変だけど。

--

メモおわり


終わったあとはラーメンを食べました。おいしかったです(こなみ

f:id:hazeblog:20181202032458j:plain:w500


感想みたいなもの

ここ最近、「自分がどこを理解できていなくて、どうやってそれを深掘りして、理解できないことをどう説明するか、調べるか」みたいなことを悩んでいて、それの足がかりになるような話がいくつか出てきてとても良かった。
アーキテクチャの分類の話は自分の中でとてもすっきり頭に入って、なるほど〜となった。
と同時に、全く理解できていない概念が沢山あるんだなと思うような話もいくつかあって、一つの言語、アーキテクチャフレームワークを突き詰めるだけでなく広く視野を持っていくことの重要性みたいなものも感じた。
特に、Back-Endに閉じているとMVVMとかは全くピンと来ないし、モバイルアプリケーションだからこその設計もある、というのが面白かった。触ってみたい。

とても楽しかったし、勉強になりました。開催してくれたダンボーさん、会場用意してくれたnasaさん、takasekさん(先生)、一緒に参加してくれたみんなありがとう〜〜

「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加しました #cookpad_tech_kitchen

cookpad.connpass.com

Cookpad Tech Kitchen に ブログ枠 で参加してきました。課題となるレポートエントリです。

目次が長い><

場所: クックパッド株式会社

恵比寿ガーデンプライスタワーに潜入するのは2回目。
この時期はイルミネーションで輝いていて、独り身にはつらい。

f:id:hazeblog:20181128235724j:plain
ビル前
(移動しながら撮ったからぶれまくっている)

オフィスはとても綺麗で、入った瞬間にめちゃくちゃ広いキッチンがある。羨ましい

info.cookpad.com

概要

クックパッドオフィスのキッチンで、開発について知見や学びを共有する勉強会「Cookpad Tech Kitchen」。第20回は技術部開発基盤グループから3名が登壇し、クックパッドにおけるマイクロサービスプラットフォームの現状についてお話したいと思います。

タイトル通り、マイクロサービスの運用に関するお話を3つ聞く会でした。

以下はその内容、およびそのメモ。と、補足。
一応参加してない人にとっても(前提知識があれば)理解できるように書いたつもり。

聞きながら買いたメモを書き直したり、わからなかった用語を調べてたら遅くなりました :bow:

@クッ社の方々
間違っている表現、用語、説明があったら教えてください。修正します

挨拶/会の説明

@hogelog さん

Cookpadの技術部の説明

  1. 技術部?
    -> サービス全体、横断的な技術課題を取り組む部署

技術部の構成

  • モバイル基盤グループ
  • ユーザ決済基盤グループ
  • 品質向上グループ
  • 開発基盤グループ
    • お台場チーム (※ cookpad_all というでかいRail Applicationをどうにかするチーム)
    • プラットフォームチーム (マイクロサービス技術基盤の開発、および運営を担当)

サービスメッシュの構築と運用

発表者: @taiki45 さん

speakerdeck.com

Agenda

  • 背景の説明
  • クックパッドにおける課題
  • 導入
  • どんな良いことがあったか?
  • 次の課題

Cookpadの組織について

料理に関する様々なサービスを作っている会社です。
プロダクトは レシピ共有サービス( cookpad.com )がメイン

組織規模: サービス開発者は200+ , サービス数は100+
サービスチーム(サービス毎に存在) + SREチーム

使用技術はRailsがメイン。たまに他言語。

SREチーム(おそらく技術部)の目標

=> 現在中央集権的に行なっているサービス運用を、サービス毎に自律的にできるような仕組みを作ること。

もともとあった課題

  • 歴史を踏まえた運用の課題

立ち上げ当初はモノリシックな1つのRails Applicationを運営すればよかったが、今は沢山のアプリケーションがある。

「1つのアプリケーションが死んだら複数のサービスが落ちてしまう」
「サービスが増えて連携すればするほど障害がおきた際の根本原因の調査が難しくなったり、障害の対象範囲の把握が難しくなる」

といった課題が出てきて、運用方法をちゃんと考えよう、という流れになった模様

ソリューション

ライブラリとかマネージドサービスで楽をしたい!!!

Expeditor

github.com

マイクロサービス運営において、障害が起きた際に影響を小さくすることができるやつ、との説明がありました。
聞いたことがなかったので調べたら、クックパッドの開発者ブログが出てきました。
というかこのライブラリ自体、クックパッドOSSだった。

techlife.cookpad.com

クックパッドの開発者ブログ曰く

リクエストを並行処理したり、よしなにリトライしたり、あるサービスで一定以上のエラーが発生したら、一定期間そのサービスへのリクエストを停止する。

もの。

AWS X-ray

AWS X-Ray (製品や分散アプリケーションの分析とデバッグ) | AWS

いわゆるDistributed Tracing, 分散トレーシングを提供するAWSのサービス。
サービスマップを良い感じにシュッと作れる。

ただ、これらは Ruby (on Rails) プロダクトであれば便利なんだけど、それ以外の言語/技術だと使えない。特にExpeditor。gemだし。
x-rayAWSが頑張ってくれているから割と対象多いけど

サービスメッシュの検討と概要

言語ごとの対応とかは置いといて、「ネットワークプロキシを間に挟んで、それにアクセスをコントロールさせる」という方針が良いのでは、という話に。
その手法を取ることで、アプリケーションがどんな作りになっていても関係なく、ネットワークレベルでの制御が可能になる。

サービスメッシュ

SRECON America 2017での発表でSREチームが言葉を知ったことがきっかけらしい。

どんなもの?
-> 今までライブラリレイヤでリトライやサーキットブレイキングをしていたものを、外の別のプロキシに任せる
-> そのネットワークプロキシを、中央の別のもので管理する

中央管理にすることで、運営チームであるSREが管理をしやすく、分散していないため監視が行いやすく秩序を保ちやすい。

Envoyについて

www.envoyproxy.io

上記で説明した「ネットワークプロキシ」に該当するOSS
当時(2017年前半)の段階では一番良いプロダクトだったので採用となった。
Istioという別のものがあったが、そちらはKubernetes前提で作られているプロダクトなこともあり、ECSを使っているクックパッドでは見送りとなったらしい。

サービスメッシュ、Envoy採用における目的と目標

Resiliencyの設定を一覧で見れるようにしたい

resiliencyの意味・使い方 - 英和辞典 Weblio辞書
Reciliencyという言葉がピンとこなかったのでぐぐった。 「弾性力」「回復力」といった言葉らしい。
話を聞く限り、リトライやタイムアウトに関する設定、リクエストの飛ばし先、その他諸々のネットワークプロキシが管轄する設定を全サービス分一覧で見れるようにしたい、ということっぽい。

クックパッドでは、(前半でもかいたけど)サービスを開発・運用する担当がサービス毎にあって、それらを横断的に見るためのチームが存在している。その横断チームのことを「中央」と呼んでいて、この後は説明が面倒なので "中央" と呼ぶ。

その中央で横断的にサービスを監視し、及びどういったプロトコルで通信をし合うかを管理・管轄できるようになることが今回の目的。

リクエスト量、その他諸々の可視化をするためにPrometheusを採用している。

仕組み

Envoyに便利なAPIがあるのでそれを使う。
各サービスのconfigファイル(アクセスポイント、リトライ秒数、タイムアウトの判断秒数など)はS3で保管する。それを元にプロキシの設定を行う。
JSONをやり取りするマイクロサービス: APIサーバはELBを使ってロードバランシングしているため、EnvoyはELBへアクセスする。
gRPCをやり取りするサーバはロードバランサに対応していないため、サーバへ直接アクセスする形を取る。

configファイルの詳細

Route Config: path毎に設定を記述する。リトライ、タイムアウト秒数など
Cluster Config: どこにリクエストを飛ばすか、といった設定を記述する。先はだいたいELB

EnvoyのAPI

Service Discovery Service API というものがEnvoyに生えていて、それを叩いて設定を変更したり諸々を適用する。
lify/discovery という参考実装が存在したが、要件が合致しなかったらしく cookpad/sds を自作した。らしい。

github.com

正直なところここら辺からよくわからなくなりました

Prometheusの画面紹介

障害が起きたときにどうなるか?

-> retry overflow counter などの値が異常値を示すようになる

何がよかったか?

一時的なエラーレートの上昇などの対応が、リトライやタイムアウトの設定によりだいたいなんとかなるようになった

それにより、エラーが多少起こったりしたとしても問題のない範囲でリトライを実施したりといった形で自動対処ができるようになった。
=> SRE等の運用コストが減った

configの中央管理化によるメリット

各サービス毎に各々で管理されていた設定が集まることで、適切な設定を行いやすくなった。
サービスレベルや、ヘルスステータスの一覧表示、状況の監視がやりやすく、わかりやすくなった。

これからのミッション

  • EnvoyのAPI(xDS)のバージョンアップなどを行なっていく予定とのこと

gRPC in Cookpad

発表者: @ganmacs さん

speakerdeck.com

2017卒とのこと

もくじ

  • これまでのサービス間連携
  • gRPC運用
  • rubyでのgRPC

これまでのCookpad

前からマイクロサービスは推進していた。
Garage, GarageClientでAPIを共通化してたり、Autodocでドキュメントを自動生成したりしてきた。

github.com

github.com

github.com

Cookpadほんと色々gem作ってるな)

なんでgRPCを導入するのか

  • IDLとスキーマが欲しい
    • IDL: Inrerface Description Language
  • RESTだとマッピングつらい
  • 他言語も積極的に使えるようにしたい

gRPCについて

grpc.io

Protocol Buffersでの定義の紹介

grpc.io

シンプル

動作環境

  • hakoっていうツールを使っているらしい(Dockerのデプロイをするやつ?)

github.com

  • cookpad/sds + Envoy でClient Side Loadbalancing

slow startについて

※Slow Startって?
-> サーバを立ち上げた直後はリクエストの送信量を少なめにして、安定する(と仮定)に従って、少しずつ送信を増やしていくサービスイン時のやり方。

富士通のこの記事がわかりやすかった
負荷分散入門(ロードバランサ入門) 第8回 連続サービス機能 : Fujitsu Japan

サービスひとつに対し、 app コンテナ、 front-envoy コンテナ、 envoy コンテナ、registrator コンテナが立ち上がる。
動きは言葉よりスライドを見た方がわかりやすそう(12ページ〜)

speakerdeck.com

registrator がappにヘルスチェックしてくれるのが良い

サービス間通信の動き

Service1: App -> Service1: envoy -> Service2: ftont-envoy -> Service2: App

リクエスト送信をenvoyが、受信をfront-envoyが担当している

Protocol Buffersの管理

Protocol Buffers定義用のリポジトリがあってサービスごとにディレクトリがわかれてる

repos/
├── service_a
├── service_b
└── service_c

lintがあったり、ドキュメントを自動生成するツールが用意されていたりと色々楽そう

メトリクスを取る

Envoy Status っていう機能がEnvoyにもともとあって、それを利用
アクセスログはサービス開発者が1〜2行シュッと定義を書くだけで取ってこれるようになるらしい

Prometheus, Grafanaを使っている

Ruby / Rails でのgRPC実現

grpc っていうgemがある

grpc | RubyGems.org | your community gem host

grpc-tools gemでサーバ/クライアントのコードを生成してくれる、あとは実装を書くだけでOK

grpc-tools | RubyGems.org | your community gem host

Interceptorや一部ライブラリは自作

その他諸々

rails runner使っているとのこと
rakeはなんかハマるらしい :thinking:

griffin

github.com

gRPCのつらみ(CPU使いきれない toka Graceful Shutdownがなかったり toka 諸々)を解消するために作っているgem
grpc gemが良い感じになったら戻れるように互換性を気にして作っている

移行中らしいです

今後

Amazon ECS の安定運用

発表者: Kohei Suzuki さん

Twitterアカウントわからんかった(´・_・`)

speakerdeck.com

もくじ

環境

ほぼ全てのアプリケーションがECS上で稼働、一部Fargate。
(FargateにしているのはECSクラスタ自体を操作するやつとか、でかいCPU/Memが必要なジョブ)

ECSクラスタ: 40
ECSサービス: 500

コンテナインスタンスの管理

比率: オンデマンドインスタンス =1 / スポットインスタンス =4

オンデマンドインスタンスのオートスケール

AutoScaling GroupとECSクラスタが1:1
AutoScalingの役割 -> desired capacityを上下すればクラスタの増減ができるようにする / 障害時の自動復旧

Auto Scaling グループ - Amazon EC2 Auto Scaling (日本語)

スポットインスタンス

Spot Fleet
役割 -> target capasityを上下するだけでクラスタの増減ができるようにする / 障害時の自動復旧

EC2 Fleet – Manage Thousands of On-Demand and Spot Instances with One Request | AWS News Blog

サービスアウトの話

interruption noticeが通知されてから2分以内にサービスアウトをこちらでやらないと強制的に殺される。
自前でELBのtarget groupから外したら止める + 突然一部タスクが死んでも大丈夫なようにちょっと余裕を持ったキャパシティのプランニングをする

スケールイン、スケールアウトの基準

  • 共通: CloudWatchのCPU/Memory値
  • スケールアウト: 各サービスのdesired_count, running_count、バッチジョブがリソース不足で失敗したとき

ログ

コンテナのstdout, stderr

fluentd経由でAmazon S3保存、Athenaで検索できるようにしている。
CloudWatch Logsはログが多すぎて使い物にならなさそうだったので使わなかった+高い とのこと

コンテナインスタンスのホストにfluentd -> fluentdの集約ノード -> S3

aws.amazon.com

モニタリング

アプリケーションコンテナのモニタリング

cAdvisor, Prometheus, Grafanaで実現

GitHub - google/cadvisor: Analyzes resource usage and performance characteristics of running containers.

今後

QAディスカッション

サービスメッシュ

retryの冪等性担保ってどうやってますか

  • getとheadはそのままでOK
  • postはパス毎に設定をしていて、「このパスはリトライ化」みたいにしてたり
    • デフォルトはオフ

istio検討してますか

  • 現状で問題ないと思うので。入れ替えて導入するよりは他のところにリソースを回したい

istio.io

gRPC

git submoduleつらくないですか

  • 特につらくない

grpc-webの導入って検討してますか

  • Envoyに便利な機能があって、フロントからgRPCで投げられてもすぐ対応できる?らしい

インタフェース設計の共通化とか

  • 基本的にインタフェースはこちらは関与せず、アプリケーション開発者に任せている

ECS

Kubernetes, EKS採用しないんですか

  • オートスケーリングツールを運用できるほどの人員の確保は難しい
  • ECSはマネージドなので良い
  • EKSはECSより現状使いづらいのでなし

OSSの運用しんどくないですか

  • そこまで
  • 英語でのコミュニケーションがつらい
  • 社内事情と強制的に区切らなければならなくなるため、分離ができて良い

ECSクラスタの分け方ってどんな単位

  • 用途+セキュリティグループ
  • 具体的には、Web App用のクラスタ、バッチジョブのみ起動するクラスタ など
  • オートスケーリンググループなどの設定がやりやすい、セキュリティグループを全て同一にしたくない

共通

マイクロサービス化の始めるタイミング

  • 規模が大きくなってきたら
  • コミュニケーションコスト>マイクロサービス化のコスト になったらやる
  • 人数でいうと150+が目安?

質問2つぐらい聞き取れなくて抜けてます

中央部分の耐障害性

(ありがとうございます)

懇親会

キッチンで作りたてっぽい色々を食べました。おいしかったです

懇親会中にスタッフの自己紹介タイムが入ってたけど全然聞けてなくて残念

感想とか

100+ 規模だからこその取り組みという感じで、とても面白い事例を知ることができて良かった。
エコシステムや既存のツールをどう使って課題を解決していくかといった話に対して、自作ツールをガンガン作っていけるのはかなり強みな気がする。
とはいえやりすぎるとそれはそれでつらいので、OSS化したりするのは良いと思った。

Container, AWSのサービス群に詳しくなくて、その場で調べながら聞いていた。多分他の人もだいたいそうなんじゃないかと思う

実際に各々の環境で使っていくかはさておき、名前が出てきたツールやサービスは概要だけでもさらっておくと、たまに役に立つ気がするのでおすすめ。

要望、というか自分が気になったのは、今回はプラットフォームを作る側の話だったけど、 それを使ってサービスを作る開発者側の意見。
これによってどれぐらい楽になったか?とか、アプリケーション側でハマったところ、とか、気になる。

aws.amazon.com

ところで、AWS App MeshがEnvoyを中で使っているとのこと。共通点とか違う点が少し気になる。
まあ、東京リージョンには暫くこなさそうだけど。。。


Cookpad Teck Kitchenは初めて参加しましたがとても楽しかったです。また行きたい。
運営の方々、懇親会で話してくださった方々ありがとうございました!

「一番下手くそでいよう」のつらさ

最近進捗がnullでつらい。はぜです。
ここ一年色んなことで悩みっぱなしというか、思考がふらふらしていて、良くないなーって思いながら生活している
そう至る考えとか、現状の課題とか、そういうことの棚卸しをやっておくと今後何かと役立つだろうし、何か大きな選択をするときに指針になるかなって思って色々表現しようとずっと紙にまとめたり、たまにブログ書いたりしています。

参考:

hazediary.hateblo.jp

まあ、何かというと、このエントリもそういう類のものです。独り言です。


仮にもプログラマ/エンジニアという役割で仕事している人間ということで、それなりにインターネットで情報収集をしたり、土日にコード書いてみたりしているんですが、
業務外に勉強するしないとか、どうすればキャリアアップができるか、みたいな話でTwitterとかはてブとかQiitaで盛り上がっていますね。

で、よく話にあがる意識付けとして、「情熱プログラマー」の "一番下手くそでいよう" という言葉があります。
どういう意味合いかというと、すごく出来る人たち(=自分が一番しょぼい)で構成されている環境に身を投げれば、その中で頑張ると自分の能力も環境に適応する形で伸びていく、というもの。

自分は偏差値的にも能力的にも低みの世界に居て(所謂誰でも入れる専門学校)、その数年間、周りと協力してコードを書いたり技術的な話ができず、一人でずっと勉強していたことがあり、そういうこともあって強い人たちがどれぐらいすごいのか、自分の範囲外の技術や物事を全く知らずに生きていた。
それを今かなり後悔していて、これからはそうならないよう、前述した 一番下手くそになれる 環境に可能な限り飛び込んでいるつもり、で、仕事していたり、コミュニティに入ってみたりしています。

とはいえ、それはそれでつらいものがある、ということを最近感じてきた。
つらい部分は、一言で言えば 自分がその人たちに対して価値を提供できていない、とか、役に立てていない、と感じること。

環境を変えることで、当然知らないような分野の知識を要求されたり、その業界だと当然知っているべきような知識が無かったりすることが最近多くて、ここに居て本当に良いのか、みたいな、ことを考えてしまう、というわけ。
特に仕事の場合は給料を貰って、福利厚生を得た上で働いているので、給料分の成果を自分が出せているのか、みたいなところに落ちてくる。

当然その足りない穴の部分を埋めるために本を読んだり、コードを書く練習をしたり、仕事をするわけだけど、いつまで経ってもその穴が無くなるわけではないような感覚になる。
「苦手な部分より得意な部分を伸ばせ」という感じの言葉もよく聞くんだけど、それ以前の、前提となる部分が足りなかったりするわけです。


エンジニアの学習って、手を動かす部分と、方法論みたいな部分と、座学等で知ることで理解できる概念的な部分があり、それを繋ぎ合わせて能力を身につけて行くんだけど
手を動かしている回数・量も足りていないし、方法論みたいなことも経歴としてほぼ存在しないし、概念の理解も環境を変えた瞬間に一気に内容が変わって、自分が足りている、得意とする部分ってなんだっけ、みたいな感じに。


少なくともこの環境にいることで能力値は上がっているし、知らないことを知ることもめちゃくちゃ多いし、自分の今後のことを考えるととても良いことなんだけど、
ちょっとずつ精神的に疲れてきた、という感覚がある。

少し休むべきな気はするんだけど、進捗の部分とか、単純に周りをみた時の差に追い詰められているのか、頭の中でずっと考え事をしてしまうことが多い。。

というか単純に余裕が無くて、どうやって時間作って勉強するんだろう みたいになって短絡的な発想になりがち。良くない。


という状況。
直近だと年末年始の予定を全て空けていて、がっつり休む予定(外行っても人多いだろうしすることもないだろうし)なんだけど、それまで頑張り続けられるかなーってふと思って書いた。

職場は一言で言ってエンジニアにとっては最高っぽい環境だし、人はエンジニアも、営業も、他の職種の人たちもとことん(このエントリみたいなことを思う程度には)すごい人たちばかりだし、良いんだけど、自分が追いつけなくてつらい。というだけです。

どうあがいても一歩ずつしか道は進めないし、仕事でつよい人から学んで、自分でもできる範囲で効率良く勉強して、追いつくように、越せるように頑張るしかないんだけど、
とはいえ、疲れる。72時間ぐらいずっと寝ていたい。にゃーん。

日記: SPAでリロードしたら404になる問題, その他

トップページ以外でリロードしたら404になる現象が起きて、ちょっと考えたら、まあそうだよなってことですぐ解決した。

/works にダイレクトアクセスしたときに、それに対応するファイルが存在しないとindex.htmlに届かずにnginxに404で弾かれる。
冷静に考えたら当たり前だけど、react-routerが勝手にやってくれるやろって思って考えてなかった。
その手前で死ぬのか。なるほどな〜ってなった。

トップ( /index.html )のリンクを踏んで /works に遷移するとreact-routerがルーティングしてくれて、index.htmlの div = root のまま更新する分のコンポーネントだけ再描画してくれるから問題が起きなくて、リロードだけ問題になる。この説明であっているかはわからない。。。

ちなみに、create-react-appで作っている途中だと、 webpackDevServer.config.jshistory api foolbackの設定が書かれていて気付かない。nginxもかまさないし。

[nginx.conf]
...
        location / {
            try_files $uri $uri/ /index.html;
        }
....

try_filesは、最初の引数から順番にパスに合致したファイルが存在するかを確認するやつで、
$uri はそのまんまURL, $url はURLに / を追加したもの
それらが存在しなかったら、 rootdir/index.html を探しに行くっていう流れになる。(当然そのindex.htmlもなかったら404になる)

この辺の設定、あんまりちゃんと理解せずに適当にコピペしたりしていたけどそろそろちゃんと中身理解しておかないと変なところで躓きそう。気をつけよう。


wakateweb.connpass.com

若手エンジニアイベントで雑にLTした。LTすることを2日前まで忘れていて急いで資料を作ったら、7分の発表なのに30枚オーバーとかになって頑張って削った。
なぜか偶然前職の人がいたり、若手(なのに)でPerlを書いたことがある人が多かったり、色々あって面白かった。

市場価値と自分の技術に対する興味 - はぜにっき
前の記事にも書いたけど、大きな技術特化のイベントとかで話せるようなぐらい専門的な知識をつけたいなあって一瞬思ったりした。
でもその前に、仕事にも影響が出ている設計周りの知識と実感(?)の無さ、頭のついていかなさをなんとかしないといけないなーっていう気持ち
がんばろう

ポートフォリオサイトを作り直した

f:id:hazeblog:20181111232016p:plain

一気に素っ気なくシンプルなページになってしまった。


github.com

こんばんは。はぜです。

プロフィールページみたいなものを作った(仮) - はぜにっき

フロントエンドの知識が全くなくてつらい - はぜにっき

半年以上前に作った haze-page.tokyo というポートフォリオサイトをSPAにしてみました。
アイコンとかサイドバーは semantic-ui-react を使った。知ってる人は一瞬でわかると思う。

create-react-app-tsをejectして、 semantic-ui-react入れて、react-router, react-router-domを入れて中身書いたら終わった。
2時間ぐらいで出来ると思って日曜日の昼から手をつけ始めたら、思ったより自分がCSSを理解していなくて、重ねて表示ができなくて困ったり、意味わからん場所にテキストが表示されたりした。
ぐぐりながら脱線したり、戻ったり、semantic-ui-reactをうまく使いこなせずに気付いたら22時過ぎ。つらい1日だった。。。

create-react-app, デプロイの方法を全く調べずに作っていて、できた瞬間にやり方わかんねえ〜〜ってなって困るなど。
npm run build して、buildファイルをサーバに投げて、nginxのrootディレクトリ設定変えただけで終わった。最高。

jestとか、その他諸々の全く使っていないライブラリをどうにかしたい。
というか使えるようになりたい。

とりあえず頭に浮かんだ画面をどうやって描画していくか、の練習になったのでよかった。
次はAPIを叩いたり、他のライブラリを使って良い感じのサービスを作りたい。API設計とかまともにやったことないからそこらへんも調べたり練習しなければ。。。

市場価値と自分の技術に対する興味

「エンジニアとしての市場価値を上げるために、今自分に足りていないこれを勉強しよう」っていうの、出来ないんですよね。
社内の誰にも負けない範囲の能力が一つ以上あると存在価値が上がるだろうし、
それこそ本を出したり発表をしたりできるようなレベルだったら会社をやめたとしても他の会社でも同待遇で雇われることができたりするだろうけど。

なんというか、組織の課題を解決する・目標を達成するために自分に足りていないものを習得するのはできるんだけど
自分の市場価値を上げるためにとか、エンジニアとして自分が強くなるために、みたいな発想にならない。

一応、技術者として仕事しているからあんまり言わないようにしているんだけど、
自分自身はあんまり好きな技術っていうのとか、好きな言語とかって特になくて、
課題を解決するための仕組み(=サービス)を作ったり、目的をどうやって楽に達成できるかを考えて、その時その時で必要な技術を習得してる。

最近はバックエンドエンジニアとして入社したけど、フロントエンドも見れた方がサービス・開発組織全体を俯瞰して見れそうっていうことでReactを触り始めていたり、
単純に機能開発で必要になるからRailsを触っていたり、社内のソースコードを読んだり、GraphQLがわからんって言ってる。

でもそこまで深い興味があるわけでもないから、rails/railsのソースを読もう!って気持ちには全くならないし、メンテナになりたい!とは思わない。
オープンソースコミュニティへのコントリビュートは自分ができる範囲でやりたいとは思ってはいる。これは単純に自分のためというより、感謝の分を返したいという気持ちから)


なんでこんなこと書いてるかっていうと、
最近Microservicesやアーキテクチャ周りに興味が強くなっていて、なんでだろうなーって考えて、
プロダクト開発をする上で、変更に対する影響範囲を小さくして安心したものづくりをできるようにする、一つの機能の開発速度を上げるようにできる仕組みを確立することで、
最初の方に書いた目的の達成や課題解決に繋がるからなんだろう、ということな気がしたから。

Microservicesっていう技術や、各種アーキテクチャそのものに興味があるわけではなくて、それを使うことでどれぐらい開発が早くなるのか、改修が楽になるのかを知っていきたいっていう結論になった。


とは書いているんだけど、一個一個の技術に対して深く興味が沸いてないのって、深く技術を見れるほど精神的な余裕がないっていう現れなんじゃないかなあと感じたりしている
自分の思い出せる限り1年以上安心して過ごしている感はないし、常に危機感というか、現状に対する焦りがある、それを無くせば別の見え方ができるんじゃないかなーと思う

でもまあ、焦りの感覚が無くなったら自分何にもしなくなりそうだし、どうなんだろう。よくわかんないや。