ぺい

渋谷系アドテクエンジニアの落書き

Bonfire Backend #2 参加レポート

f:id:tikasan0804:20181209172453p:plain

yj-meetup.connpass.com

イベントの参加レポートです。スライドを見ればわかる内容はここでは書きません。

Apache Kafkaによるログ転送とパフォーマンスチューニング

www.slideshare.net

この発表では、Kafkaについての発表でしたが、起きた問題については、リクエスト数が多いサービスなどでは、既知感のある課題でした。
僕もいまの会社で似たような問題に直面したことがあり、チューニングするなどをしたことがあったのですが、やっぱ、人々はログストリームどうする問題に直面しているんだな・・・って気持ちになった。

スライドでは、細かい仕様が示されてなかったので、サービスの特徴は想像するしかなかったのですが

  • Producerの数減らせない
  • Partitionを減らせない
  • タイムアウトを長くできない

などの制限があったそうで、なかなか、面倒そうだと思う一方で、Kafkaはかなり色んな便利機能を用意してくれてるんだなーということが分かった。 弊社では、ほとんどのサービスをAWSで構築しているので、Kinesisに比べてKafkaどうなんだろう?とか気になっていたので、ちょうど色々話が聞けてよかった。

Better docker image+

speakerdeck.com

Dockerについて、ひたすら語る発表でした。たまたま、EC2などで動いていたサービスをコンテナ化をして、Fargateで動かすなどをしていたので、Dockerのベストプラクティス周りの話を聞けてよかった。 特にこれから、Docker使っていくぞい!って人にはかなりおすすめな内容でした。

  • curlwgetで何か取得する時に遅い問題に対して、並列ダウンロードで解決するは、盲点だった
  • buildkitをとりあえず使ってみよう
  • dockerについてここまでやり込むのは単純にすごいと感じたw

Akka streamsを活用したログ集計に優しいデータフローの構築

speakerdeck.com

adtech studioのログ集計で、Akka streamsを使った話でした。僕も現在、アドの開発、運用に携わっているのですが、あまり他社の実装例を見る機会がなかったので、興味深い内容でした。

  • 既存の置き換えに、Firehoseってそのまま使えないのわかる
  • 便利そうだけど、Akka stremesの管理コストとかどうなんだろとか、いちいち思う自分は、フルマネージドサービスを使って済ませたい側の人なんだなと聞いていて感じた

広告配信サービスにおけるパフォーマンス対策、やるかやらないか

speakerdeck.com

弊社のCTOの @katzchang による発表でした。内容としては、パフォーマンスチューニングに対する取り組みについての、現場感のある発表でした。
実際のところどうなの?って話ですが、弊社の開発のノリそのままです。

この発表を聞いて、改めて実感した弊チームの良い点は、 イデアを試せる権限を与える でした。配属されてから、当たり前のように本番環境へのデプロイをしたり、本番で計測してみたりを、この前まで学生だったひよっこエンジニアにも出来るように権限が与えられている点です。これによって、改善しようと思えば出来るという環境が整っていることです。

最初は、本番に何かするというのは、恐怖に近い感覚を持ちましたが、いまはそれが出来るお陰で、スピード感を保って開発が出来ているんだなと確信している。

SpeedCurveを駆使した継続的なパフォーマンス改善

www.slideshare.net

パフォーマンスの改善したいけど、わりと大変だったりするし、何か新しい機能が増えるわけではないので、実際やろうと思うと、色々ビジネス観点のメリット見えにくいから進めにくいですよね?みたいな話でした。

技術者目線、サービス目線を見て、両者が納得をもって進めれるWin Winの仕組みがあるそうで、それは、サービスのKPIとパフォーマンスの因果関係を証明すれば、改善しても良い というものでした。企業規模の大きい会社でも、フットワーク軽く動けるように、仕組み化までしていて、素直にすごいなと感じた。

感想

東京に来てから、わりと知識欲が満たされがちで、勉強会を開催するも、参加することがあまりなかった僕ですが、友人が中心となって主催していたことや、弊チームのCTOが発表することもあり参加しました。
全体的に自分にとってタイムリーな話題や、気になっていたことが発表で出てきたりと、最初から最後まで楽しめた。また、バックエンドと題しているだけあって、踏み込んだ話が多かったのも良かった。(個人的にはもっと具体的な話でも良いくらい

運営のみなさま、お疲れ様でした。また、参加出来そうなら参加したいと思います。

絶対に仕事を安請けしない

安請け合い・安請合い

( 名 ) スル
確信もないのに請け合うこと。また、軽々しく引き受けること。 「 -して後で困る」

大体出来るけど、安請けしない

仕事をやっていると、「これ出来る?」という話が結構出てくる。大体出来るんだけど、すぐに「やるよ」とは絶対に言わない。

課題解決は大小問わず、脳が疲れる

何も考えずに「やるよ」としてしまうと、いま進めているメインタスクから、脳を切り替える必要がある。個人的に違う仕事に切り替えるは、スーパー重い処理だと感じている。もし、そのタスクが終わったとしても、削れた集中力はもう戻ってこない。

※緊急度の高いバグとかは別です。時間問わず対応します。

「やるよ」ではなく、「なんでやるの?」を議論する

既存の仕組みでなんとかなることもあるので、すぐ出来る解決策を検討する。既存の仕組みだと出来ない場合は、「なんでやるの?」をヒアリングする。そして、絶対やった方がいい!ってなったら、やる。かもしれない。それくらい、何かの仕事を中断してまでやるってのは重い決断だと思っている。

やるとき

大体の場合、メインで進めているタスクが終わったら、次やろっかに落ち着くことが多い。けど、それで良いことが多い。なんでかっていうと、既に優先度が高い仕事をやっているので、逆転することはそうそう起きない。

半年間の社会人生活で学んだこと

社会で生きてみた

VOYAGE GROUP、Zucksでの社会人の半年を振り返りをしてみた。

技術

がっつりとか、少しとか色々あるけど、本当たくさん経験が出来た。

  • Go
  • Scala
  • Lisp
  • PHP
  • Python
  • BigQuery
  • HTML
  • CSS
  • JS
    • React
    • Angular
    • Vue
  • AWS
    • Lambda
    • EC2
    • Batch
    • ECS
    • Fargate
    • S3
    • Dynamo
    • なんかもう色々
  • CI
    • CircleCI
    • Jenkins
  • Packer
  • Docker
  • Vagrant
  • なんか色々あった気がする

経験したこと

  • リリース作業
  • リバート作業
  • 設計
  • コーディング
  • ヒアリング
  • レビュー
  • ミーティング

配属当初は本当に色々あった

  • うまくコミュニケーションが取れずに手間取る
  • 設計の掘り下げが甘くて手戻り
  • リリース作業心労し過ぎて腹痛
  • 諸問題で何回もリバートしたりした
  • 体調バグりがち
  • リリース作業中エラー起きたらパニクる
  • 周りが優秀過ぎて、自分の意見に自信が持てない

変わったこと

  • リリース前に最悪のケースを想定する
  • コードを書く前に具体的な設計を練って、相談をして手戻りなくす
  • 結果を出すことに執着し過ぎず、多少時間かかっても、確実に終わらせることに集中する
  • しんどい時は、帰る
  • 起きた時にしんどい時は、諦めて寝る
  • 家で勉強する習慣をやめた(本当に必要だと思うものだけ勉強する)
  • 人が言ったことを鵜呑みせず、本当か?って姿勢で議論する
  • 頑張ってるという感覚までやるのをやめた(自分の場合、やりすぎになっている)

残りの半年間やっていきたいこと

いつも、最高のパフォーマンスで業務に臨める時間を作れるように、良い感じに生活する。

「するべき」というパワーワード

あまり強い言葉を遣うなよ

tikasan.hatenablog.com

以前アップした記事にあった「するべきこと」に対してのコメント @ 弊社Slackの個人チャンネル

f:id:tikasan0804:20181006135912p:plain

自分はあまり気にせず使ってしまっていたので、何故だろう?を考えてみた。

Abuse of “should“ or “shouldn’t” e.g. We shouldn’t have interruptions…”

参考資料として貼ってもらった記事を雑に翻訳。

medium.com

「するべき」または「すべきではない」の濫用。 例えば、我々は中断してはならない... 。

中身がなく意味がないレトリック。
「私達は皆、豊かでなければならない。」
「本当に?私達はより良い新しい車を持ってる必要がありますか?」

実は、私達が”すべき”を使う時、目の前の現実を受け入れていません。実際にシステムを見ていません。スタートが基本的な透明性が失われいる場合、どのようにして、効果的な変化を望むことが出来ますか?

”すべき”はいまの既存バージョンの理想郷の説明することが出来ます。それは私達が目指している場所の表現として良いかもしれません。Kataのアプローチは、”すべき”というシチュエーションを打ち消し、コーチングするのに有効なテクニックです。

Abuse of “should“ or “shouldn’t” e.g. We shouldn’t have interruptions…”

More empty rhetoric. We should all be rich, am I right? We should all have better, newer cars, ya get me?

The thing is, when we use the word ‘should’ we are not accepting the reality in front of our faces. We are not seeing the system as it really is. If our starting point lacks this basic transparency, how can we ever hope to be effective change agents?

‘Should’ can describes a utopian version of an existing scenario. That might be a good expression of where we want to get to. The kata approach can be a good technique to counter and coach these ‘should’ situations.

Kataとは、日本のTOYOTAの行っている型というアプローチのことらしいです。
わかりやすい記事があったので紹介させていただきます。

radiocat.hatenablog.com

  • 問題を取り上げる
    優先度の高い問題を見つける
  • 状況把握(行って見る)
    問題の発生点を見つけても台を明確にする…問題の発生点を見るけるまでは対策に入らない
  • 原因を調査
    5回の「なぜ」を行う
  • 対策をつくり試験する
    一度に1つしか変えない
  • フォローアップ
    ふりかえり

”すべき”というワードを使うことで安心をしていた

色々読んでわかったのが、すべきと言っておけば、それっぽいことしてる風に聞こえる。それが中身のないことだったとしても強いワードはパワーを持ってしまう。”すべき”はすぐに使わずに、実際に問題を直視し、見たものから状況から判断する。そうすることで、勝手にやったほうが良さそうなことが見えてくる。

”すべき” を使いすぎ。だめ絶対!

出来るエンジニアはサボる

ここ最近、実装するが人並みに出来るようになってきた。そして、いまはミニマムを作るを考えることに非常に悩まされることが多い。

どんな開発現場での文脈か

株式会社Zucksのエンジニアは、ビジネスサイドからやりたい雰囲気、またはやりたいお気持ちを感じ取って、それについてヒアリングして、どうやって作るか、そもそも作るか?というところから考え、最終的にはリリースからその後の保守まで面倒を見るというのが、普段の業務内容になります。とりあえず、実装っていうのは、この工程全体を指しています。

油断していると人間は作りすぎる

入社当初は、考慮すべきことが考慮されていないが、主な課題で、いまは、色々考慮しすぎて、設計がファットになりがち。本当に油断していると、考慮すべきでないことまで考えてしまう。
ただ、自分の場合、設計->相談->コーディングという手順を必ず踏んでいるので、ファット仕様は設計段階で指摘されるので、出来上がったものが、大ゴケするということは起きていないのが、不幸中の幸いという感じ。

出来るエンジニアはサボるのがうまい

悪いように聞こえるかもしれないけど、僕が思う出来るエンジニアは「サボる」のが非常にうまい。どうやったらそんな発想が出来るんだってくらいうまくサボる。ここで重要なのは、ただサボるのではなく、色々考慮した上で、サボるという点。最小限で作って、価値を作る。もし、問題が起きたら?は想定済みといった感じ。

やるべきことと、あったらいいよねを切り分ける。

早くサボれるようになりたい。

そして、するべきとかって問題じゃなかった問題。 tikasan.hatenablog.com

エッセンシャル思考 最少の時間で成果を最大にする を読んだけど、めちゃくちゃ良かった

とりあえず、読んでほしい

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

勤務先の同チームの先輩が読んでいたのをきっかけに、ポチってみたのですが、冗談抜きでめちゃくちゃ良かった。
この本の内容は、自分の中に留めておきたいことも非常に多かったので、今回わざわざ記事にしてみました。

この本を読むことで得られること

  • 本当に重要なことは何か?(家族や仕事、自分自身について)
  • 最も注力するべきことに注力するためには、どうすれば良い?

などが、色々な著名人の話を入れつつ、詳しく解説されています。自分の人生をどう過ごすか?について、考えさせられる内容となっています。

立ち止まって多くの選択肢を考えるが、本質的なものだけをやる

私達は、仕事をする上で、様々な課題に直面します。しかし、自分という人間は一人、やれる仕事の量には限界があります。全部やろうというのはやめる。何をいまやるべきなのか?それは本当に必要なのか?必要であれば、どうやってやるべき?どこまで?をしっかり考え抜く。必要そう、というものは切り捨て、本当にいま必要なことに注力し、最大の成果を出す。

全部をやると全てが中途半端になるし、思考を巡らせる暇がないので気持ちが忙しくなる

色々な仕事が飛んできて、それらを全て真っ向から受け止め続けると、「忙しい」が仕事を埋め尽くし、工夫をする余地がなくなる。これは本当に必要なことか?を考え、必要でなければ切り捨てる。

何事にもトレードオフが存在する。全部はやれない。何をやるべきかを考えて何かを捨てる

二兎追う者は一兎も得ず。仕事でも同じ。

遊びを作ることは不可欠。ストレス軽減にもなり、仕事も創造的になる

休日は徹底的に遊ぶ。休む。そして、業務時間中を最高に集中する。少し遊ぶくらいが、仕事に対するモチベーションを上げてくれる。

仕事ができる自信があるなら、目の前のチャンスを断って昼寝する勇気を持つ

これ以上、仕事を請け負うことは出来ないけど、大きなチャンスが目の前にあったとしましょう。もし、自分に本当に仕事が出来る自信があるなら、思い切って断って、休む勇気を持つ。そして、しっかり休息を取る。そして、本当に掴むべきチャンスを掴む。

睡眠は仕事の効率を高めてくれる

私達人間は、大半が1日8時間程度の睡眠取る必要があります(一定数ショートスリーパーという人達も存在しますが)。睡眠を取らずに仕事をすれば、成果を出せるというのはほとんど間違いで、望ましいのは、眠たい時にしっかり寝ることで、常に高い生産性を保つことができ、最終的には長く眠っている人の方が成果を出す。(ちなみに、寝不足は酔っ払いと同じくらい酷い状態らしい)

これだ!というもの以外はノーとする。90点ルール

様々な選択肢がある中で、「なんか必要そう」などで、採用するのはやめよう。そんなことでは、いつまでも本質に注力が出来ない。「これだ!」だけを選択することが、高い成果を出し続けることが出来る。(採用でも同じという話があった)

目的は完全に明確でなければ、人を動かすことは出来ない

目的が明確であれば、チームが向いている力の先も同じになり、大きな力を生む。逆に不明確な目的は勘違いやトラブルしか産まない。

達成が明確でないと、評価が出来ない

何を持って達成とするか?が分からないと、結果が評価出来ない。いま目標に近づいているのか、遠のいているのかが明確に見えることは、次の施策を考える上でも重要。

何をしたいの?が確定していないと意思決定が出来ない

結局、いま何がしたいのか?を明確にしなければ、強い自信を持って意思決定が出来ない。

ノーは上手に、きっぱり断る

やりたくないこと、出来ないことは、きっぱりと断る。中途半端に断ると相手に変な期待をもたせてしまうし、断るべき時に頼みを受けてしまうと、成果を出せずに相手の期待も裏切ってしまったり、自分の本来やるべきことに集中出来なかったりとお互い良いことがありません。断ったら嫌な気持ちになるかもしれないと思うなら、上手に断ろう。(別の提案投げてみるとか、適した人材紹介するとか色々ある)

やめるかやめないかを考える時は、1円も払ってない時でも、投資をするだろうか?で考える

何かに投資をしたり、何かを買った後に、失敗だったかもしれないと気づく時があります。しかし、人間は一度所有したものを手放すのが苦手な生物です。また、投資などはいつか成果が出るかもしれないと、どれだけ望みが薄いことでも、夢見がちです。そんな時は、一度、0ベースで考える。もし、同じものをもう一度買うタイミングがあったら、本当に買うだろうか?と、その時に買わないものは、恐らくさっさと手放すべきものです。

失敗は認めることで過去のものになる

あの時、失敗だったかもしれないと考えている間は、永遠に頭にそれが残り、集中を邪魔します。失敗はさっさと認めて、次に進もう。

やめてみたいことは、試しにやめてみる逆プロトタイプをすればハッキリする

何でこれやってんだろう?という疑問のある仕事や手続き。試しにやめてみる。本当に必要なら誰かが困り、催促が来るはず。

業務は複雑性は上がり続けるので、減らすことも大事

あることがきっかけで、ルールが増えたり、業務の工程が増えることがあります。それとは逆に必要でなくなったものは、減らすことも継続して行い。本当に必要なものだけを残す。

仕組み化することで、健全な状態を無意識に維持する

健康に過ごすためには、日々の努力が欠かせません。そういった努力は場当たり的に行うのではなく、毎日行うことが重要です。最終的には習慣化することで、健康を習慣にすることが出来る。

常に最悪のケースを想定する。そうしておけば、不測な事態も難なく越えられる。そのためには準備と計画には全力を注ぐ

なんとかなる。ではなく、どういう最悪がありえるのか?を想定することは大事。何かが起きたからでは遅いし、その対応にたくさんの労力を割くくらいなら、最初から計画を練って備えよう。

いま、この瞬間で最も重要なことに注力する。過去と未来は想像の中でしかない

私達の人生において、重要なことは、「いま」であり、過去や未来は想像の中にしか無い。いまこの瞬間に最も重要なことは何か?を考え行動することを続ける。

まとめ

上の箇条書きでは紹介はしませんでしたが、この本では、仕事のことも勿論ですが、家族とどう接するべきか?というトピックを要所々々で取り上げられていて、その度に、家族以上に重要なものはないという話が出てきます。娘の誕生日と重要な商談の日が被ったら〜とか、嫁さんとの時間の過ごし方とか、今後の家族との接し方についても、考えさせられる内容で、そこらへんも非常に良い話ばかりなので、ぜひ読んでみてください。

O/Rマッパーを使う理由

f:id:tikasan0804:20180805205507p:plain
※サムネがO\Rとなってますが、表記ブレです

記事にした経緯

私の所属するVOYAGE GROUPでは、技術力評価会という、エンジニアがエンジニアを評価する会があります。その発表の素振り、つまり、事前練習会みたいのが行われたりします。 そこで、O/Rマッパーを使っている部分の話になった時に、「O/Rマッパーって何が便利なんですか?なんで使うんですか?SQLを書いたらだめなんですか?」という質問が飛び出しました。

これは私に対して来た質問ではなかったのですが、確かに何で使おうんだろうねっていうのが言語化出来ていなかったので、まとめてみようと思いました。

O/Rマッパーとは

オブジェクト関係マッピング - Wikipedia
Wikipediaには、オブジェクト関係マッピングという名前で紹介されていました。そこに書いてある内容を要約すると・・・

データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。

つまり、オブジェクト指向とデータベースの考えの差分を吸収して、どっちでもいい感じに使えるようにする技法。

では、何故この技法が生まれたのかを理解していく。

登場した背景

オブジェクト指向言語で、リレーショナルデータベース(以下データベースとする)を使う時に、取得してきたレコードをオブジェクトにマッピングする作業が必要になります。わからない人向けに手動マッピングのコード例を貼っておきます。

※以下のコードはかなりいい加減なのと、適当にコピってきたなので、流し読みしてください

Connection conn = null;

try {
  conn = DriverManager.getConnection(url, user, password);

  Statement stmt = conn.createStatement();
  String sql = "SELECT id, first_name FROM users";
  ResultSet rs = stmt.executeQuery(sql);
  List<User> users = new ArrayList<User>();
  while(rs.next()) {
      User user = new User();      
      // usersテーブルのid を UserクラスのIdフィールドに入れる(マッピング)
      user.setId(rs.getString("id"));
      user.setFirstName(rs.getString("first_name"));
     users.add(user);
  } 
}catch (SQLException e){
  out.println("SQLException:" + e.getMessage());
}

こういったマッピングを毎クエリ書く必要が出てきます。これはオブジェクト指向言語が悪いとか、データベースが悪いという話ではなく、設計のズレ。これをインピーダンスミスマッチと言います。

  • リレーショナルデータベース設計: 検索や登録更新処理に最適なモデル定義
  • オブジェクト指向設計:データモデルを現実世界のモデルに即したものとして定義

そもそも、思想が違うので、どちらかの思想が合わせるといったことすると、不都合が起きることは当然ですよねっていうことはこの時点でわかる。それらの不都合を解決するために出てきたのがO/Rマッパーです。

O/Rマッパーがない世界感

SQLにはオブジェクト指向を考慮した設計はなされていないため、SQLを扱おうとすると、オブジェクト指向にある柔軟性のメリットが無に帰すわけです。どういうことか?

何かのSQL構築したいと考えた場合、オブジェクトに入れたデータをデータベースに保存するために、一旦オブジェクトからデータを抜き出し、SQLを構築する専用メソッドが必要があります。これだけでもだるい作業なのですが、もし、データベース側でカラム名、型の変更があった時に、SQL作成部分のコードは毎度実装修正する必要が出てきます。(再利用性とは・・・状態)

また、マッピングを書く処理は非常に単調で退屈なコードです。しかし、これを間違えると普通に事故ります。しかも、型が同じであればそれっぽく動いたりもするので、これを人間が手作業で全部やるのは辛い。(コードジェネレーターで解決するという手もありますが、今回は割愛)

使うことで得られるメリット

よくあるO/Rマッパーは、オブジェクトを作成して、データベースのデータを更新するメソッドに渡すだけで、あとはそのメソッド内で、クエリ作成に必要なマッピングを中でやってくれます。
もし、フィールドを増やしたい減らしたいといったことが起きても、updateメソッドに渡すオブジェクトに変更加えるだけで済みます。このメリットはレコードを取得する時にもです。

ちなみに、マッピング情報をxml形式で書いたり、アノテーションで定義をすることが多いです。面倒のように思えますが、そこさえ書けていれば、コードを書く時はオブジェクトを扱うように操作が出来るようになります。

User user = new User();  
user.setId(1);
user.setFirstName("hoge");

// いい感じに変換してくれる(型解釈や構文の構築など)
// UPDATE users SET first_name = 'hoge' WHERE id = 1
db.update(user);

SQLを考えなくてよくなる?

オブジェクト指向言語からオブジェクトをそのまま扱うような感覚でデータベースを扱うことが出来るようにしたのが、O/Rマッパーですが、だからといってSQLを知らなくていいというわけではありません。これはどういったクエリが発行されているのか?は理解しておかないと、「スロークエリ」や「N + 1問題」といった問題に対して何も出来なくなってしまうので、精通しているまではやらなくても、読めるようにしておくことは必須です。

そもそも、O/Rマッパーが登場した背景には、SQL理解しなくても使えるようにではなく、分かっていることを何度も書かないで済むようにしたいや、オブジェクト指向とリレーショナルデータベースのメリットを最大限発揮するために考えられたものなので、知らなくていいやという話ではないのです。

まとめ

世に出ているO/Rマッパーはマッピングだけではなく、付随して便利な機能を持ったものがたくさんあるので、ずばり何がしたいんだっけ?がブレブレだったので、学びがあった。