蚊帳の中の日記

ゆるく生きてます

「自分はどういった実装が良いと思うのか?」をもっと考えたり、主張したりすること

以前書いた

kayanaka.hatenablog.com

にも似ている話な気がしている。

先輩や熟練者の実装やレビューが正しいと思い込みすぎる癖があった気がしている

個人的な話。

既存のコードが良いだろうという思い込みにも似ていて、開発経験が自分よりも多い先輩や熟練者の方々のレビュー、指摘、アドバイスはだいたい正しいだろうという思い込みが結構強すぎる癖があったなと最近思った。もっと「自分はどうするべきだ〜」とか「こうすると良くなるかも〜」という意見や逆提案をしていくことも大事だなと。

たしかに自分よりも経験や知識が多い先輩や同僚の指摘やアドバイスは、自分が目の前で取り組んでいる問題に対して、よりベターな解決案であることが多くて、本当に学びにあって楽しい。そのアドバイス等をもらって「その通りだ!」と思ったなら、そのアドバイスを使わせてもらえばいい。

でも「確かに!」と思う半面「うーん、自分はこう思ったりもしたな」と思ったり、「うまく理解できてない箇所があるけど、きっとアドバイス通りにしておけばいいだろう」と思ってるするときもあった気がした。そういった指摘を鵜呑みにしたり、「あの人が言ってるのだから間違いではないだろう」と言わば自分で考えることを疎かにしてしまう(意識的にはそういったつもりはないのだが)のは良くない。お互いに良くない。

なにか少しでもより良い方法や考えがありそうだったら、それを出していかないと、せっかく議論の余地があるかもしれないのに、、、もったいない気がする。これまたお互いのためじゃなくなってしまう。

うだうだ書いたけど、要は、もっと自分の意見を言っていかないとな〜と思ったってこと。


やっとこさ色々と慣れてきた感があるので、これから自分なりの良さそうな考えがあれば、もっと出していきたいという気持ち。

HTML5 Conferenceに初めて参加した

今回で(たしか)7回目の開催だというHTML5 Conference 2018に参加しに北千住の東京電機大学に行ってきました(どうでもいいけど大学思ったよりもキレイだった)

f:id:kayamelo151515:20181126235231j:plain

参加したセッション

zozoのECアーキテクチャとか、WebXRとか、有名な古川さんのnodeの話とか、yahooさんのFIDO認証の話とか、他にも聴きたいセッションがありすぎて、迷いに迷って上のを聞いてきた。

メモとかしたけど、とりあえず印象に残ったことを書き留めてみる

続きを読む

既存のコードに習う実装には気をつける

既存のコードを良しとする思い込み

当たり前なのだけど、個人的に既にある既存のコードが比較的正しいほうだろうと思い込むことが多かったりする。

『まあ、既存コードがこうだし、真似すればいいよね』 『既存がこういう設計だから間違いではないよね』

既存コードを参考にするのは、サクッと開発するのには良いときあったりするとは思う。いわゆるコピペでうまく行っちゃうときもあるとは思う。

でも、上記のことばかりやっていて、既存コードに対して何も疑問を持たずに良しとする考え方になってしまうのは良くないな〜と思う(ごめんなさい。自分で言っておいて、たまにそれで良くね?って思うっちゃうときあります。反省してます)。

既存のコードが良いなんて保証はないと思うし、せっかくプログラマーやってるんだから、もっと良い設計とか良い実装を提案してリファクタリングしていくのが良いはず。 疑問に思う既存実装があったら、疑問を投げかけてみると、意外と歴史的な経緯で仕方なくそうなっていて、放置状態だったりすることもあるはずだ。そういった所を地道に直していくのも、プログラマーの仕事だと思うし、未来のために有益だったりするので、もっと既存のコードを良くする心構えと強くしたいな〜ってなんかふと思った。

AbemaTVDevelopersConf2018に参加してきた(殴り書き)

追記: 2018/10/24
公式から講演資料の共有がありました

https://developer.abema.io/2018/#timetable


普段から日頃お世話になっている(特にスポーツとアニメ視聴)AbemaTVのインフラ構成とかどうなってるのかな〜って、すごい気になっていて、今回表題のカンファレンスに参加することができたので、ざっとレポートを書き残しておく(完全に自分用。多分、スライド資料とか公式から後日まとめが出そうだし、もっとクオリティ高いのは他の記事とかを参考にしていただければ幸い)

AbemaTVの組織構造と今後の技術課題について

  • アプリダウンロード3000万突破
  • サイバーエージェントの歴史を諸々説明
  • 新卒が20名以上がAbemaTVで活躍しているらしい。多いな〜。
  • プロジェクト進行はOKRを採用している。最初は色々大変だったけど四半期ごとに改善していってやっと板についてきた感じ
  • また、中長期な品質向上に取り組むように心がけている。
  • S1〜S7までのグレードでエンジニアを評価している。
  • 最近までエクセルで目標設定してたけど、HRBrainっていうクラウド?を導入したらしい。
  • キャリブレーションも実施(.....キャリブレーションって何?笑)
  • 組織構造はプロジェクト横軸、職種縦軸で、縦串構造みたいな感じ。
  • AbemaTVのカルチャーにフィットした人を採用すことを心がけている
  • 褒める文化
  • エンジニア組織は80名程度いる。思ったより多かった。でもこれでもまだ色々人が足りてないんだろうな。Android,Iosが割合の多い、次がWEB、あとは諸々。TechLeaderみたいな立ち位置の方は15名程度いる。
  • 評価指標はNPSって指標を採用している
  • 総務省がだしたインターネットトラヒックを見ると年々爆発的に伸びていて、動画サービスのニーズも高まっている。
  • 5G、携帯料金値下げ、CDNなどの今後の通信インフラの変化にも色々準備や投資を進めているらしい。
    • モバイル回線での動画視聴が増えると睨んでいる
    • スマホ、テレビデバイスの需要が増えることも考えられる。
    • 映像クオリティも上がっていく。そのニーズも上がっている。
    • 既存コンテンツのネット配信も当たり前になってきている。
    • Amazonとかもこのあたりに非常に投資を行っている。
    • 映像配信・圧縮、4K、8Kなどの映像技術も色々見て頑張っている
  • リニア配信?、VOD?
  • 動画技術も色々と技術革新が進んでいるらしい。最後のセッションでどういった動画技術に注目しているのか話してくれるみたい。
  • AndroidTV => IPTV???(テレビに関するデバイス開発も考えている)

ここまでは組織の話

ここから技術的な話

  • アベマはチケット駆動開発で初期開発は4ヶ月程度で爆速開発!すげーーー!!!!!
  • GCPを色々活用してエンジニアは機能開発に注力できた
  • CDNAkamaiを採用していた。動画最適化に強いらしい。(当時)
  • マルチDRM対応???
  • Abemaビデオ。TVとVODの融合、、、よくわからん。
  • 配信の安定化について
    • 亀田の番組障害以降、伝送・配信の安定性と配信システムのアーキテクチャに課題を感じた。
    • 2点の観点で改善
      • Zixi(?)ってサービスを定常運用化(カメラで撮った映像をネットにあげて、初めて色々な処理が走るが、GCPの台湾リージョンを使っていて、物理的な距離とか色々問題があって処理が追いつかないことがあったらしい)
      • Cloud Interconnect導入(確実にCDNに配信する伝送・配信を安定化)
    • システムアーキテクチャの改善について
      • 配信システムが他のシステムと非常に複雑に絡み合っていた。密結合。
      • 映像配信とユーザーが使う機能を分離した。
    • スケールアウト戦略が終焉を迎えた
      • 大規模配信のときはスケールアウトでいいじゃん?って思ってたけど。。。。
      • 次回の大規模配信に向けて、システムのスケールアウト計算をしたら、物理的なリソースとネットワーク的なリソースの限界を超えてしまったらしいwwwwやばいよwwwwそんなことあるんかい?!?!
      • なので、リソースパズルをやってみる(どのリソースを増やして、どのリソースを減らすかを検討する。取捨選択。)
      • 結果、システムキャパシティを5倍に拡大できたらしい。
  • マスメディアの実現に向けて(今後について)

72時間ホンネTVの負荷対策と裏側

  • プロマネを担当した方の発表
  • 亀田の番組で障害が起きたので、次の大規模配信に向けて色々対策を行った。
  • まず、インフラ構成を書き出して、どこに障害が多くて、どこにリスクがあるのか見直す
  • ドッグフーディング??
  • あとは、負荷対策キックオフのためにログ見たり、メトリクス見たり、色々調査し始める。動画配信の未経験だったのこと。すごい。。。
  • Charlesなどを使ってリクエストを見たりして調査しまくる。すると、サーバーへのリクエスト数に無駄があった。これはうちでもやってみると、学びや発見があって面白いかもと思った。真似してみたい。
  • 具体的な対策
    • できるだけCDNにキャッシュさせる。動画のプレイリスト、ウェブブラウザ用のサイト、APIの一部のコメントとか番組表も。
    • CDNのキャッシュヒット率を向上するようにする??(リニア?VOD?)
    • 無駄なリクエストを減らす(googleのExoPlayerに不具合がありPRを出したとか)
    • リクエストのポーリング感覚(取得感覚)を調整したりする。(視聴数の数字更新機能とか)
    • またGCPだけでなく、プライベートインフラやAWSなどの別のサーバーに一部の処理を振り分けたりした。分担。
    • 負荷試験・サーバー台数の調整(@rm-rf-slantさんが書いた資料が参考になるらしい)
  • ホンネTVでは、亀田のときより、リクエスト数を10分の1くらいに減らせた!コスト削減にもなった。その後の大規模配信も特に問題がなかったとのこと。すごい。。。(さっきからすごいしか言ってない。いやほんとに。)
  • 念の為、障害レベルも定義しておいて、どういったときにどういったアクションをするべきなのか?ということを皆で認識を合わせるために整理した(実際は使わなくて事なきだった)。これは真似しても良さそう。
  • 未来の話。インターネットの限界との戦い。インターネットの限界とは。。。。。
    • IPユニキャスト通信???
    • 地上波テレビと違って、インターネットは見る人が多ければ多いほど立て込んでくるので、パフォーマンスが悪くなる。
    • AbemaTVは12Tbpsの世界。。。通信量やばい。。。Tbpsとか、、、、。
    • 色々未来のために動いてる

AbemaTVのアーキテクチャの変遷

  • インターネットでリニア型?の動画配信開発は経験が浅かった。でも色々創意工夫。
  • なぜGCP
    • 高機能L7ロードバランサを使える
    • GKE、Kubernectsが使える
    • ネットワーク帯域のコストが安いらしい(ネットワーク帯域増やすのにマシンのレベルもあげないといけないらしいのだが、GCPだとそのへんのコストカットしてくれる???GCP使ったことないからよくわからなかった)
    • StackDriverロギング、ビッククエリなどのログ収集などのサービスがある
  • (裏話)GCP台湾リージョンを選んでる
    • 日本と台湾間のインジェクトが不安定らしい
    • あとで日本リージョンもできたけど、移行に人的コストをあてられていないの現実。今も台湾リージョン(これに対する対策は後述)
  • Go言語。DBはMongoDB(GCPのデータストア使いたかったけど、編成ツール?の完成の関連でMongoにしたらしい。よくわかんないけど)、マイクロサービス。
  • (裏話)マイクロサービスの崩壊(ここ聞き逃した)
  • 番組表はスナップショットをGCSに保存している。(編成途中の番組表がユーザーに見えないようにするためらしい)
  • 配信サーバーHLS。なんかトランスコードして、メタデータとかはGCSに保存のみたいな感じっぽい。よくわからん。
  • 生配信は、HLSを配信して、インジェストサーバ(Watchman)を開発???わからん。

このあたり、自分がインフラ知識が弱いのもあり、進出単語多くて、動画系の単語も多かったから正直わからんことが多かった(泣)

  • 番組が生番組とか、収録番組とか、色々種類があるので、それによってインフラ構成が少し異なる。HLS(watchman)でトランスコーダされた動画データ(セグメント)?を取ってきて、MongoとGCPに保存して、MediaProxyでクライアントに配信するってことか????
  • HLSが肝っぽいけど、、、うまく理解できなかった。。。
  • 動画セグメントをredisにも保存するように後々なったらしい。
  • Fluentdにログを貯めてたけど、Goだと相性悪かったらしくて、GatewayのあとにCloud pubsubを挟んだらしい。

本開局後に色々改善

  • 配信サーバーから広告サーバーへのレスポンスが詰まっていたので、広告サーバーからのレスポンスをキャッシュ
  • Redisでコメントとかのキャッシュをしてたらしいので、redisクラスターのスケールアウト。でもgem(?)にバグが有ったらしい。つらい。年始にすぐに対応したとのこと。すごい。年始も休まないアベマ。脱帽。
  • 日本と台湾間のインジェストが不安定なのは、伝送プロトコルUDPベースのZixiで対応したらしい。プロトコル変更ってこと?うーん。わからん。
  • 亀田の障害はmongosのコネクションが詰まってたので、mongoDBを再起動して解決したらしい。また、後日ドメインとか色々分けないでごっちゃでredisとかmongoに保存していたので、色々ドメインごとに分離をした。(配信とそうでない部分で分けた)
  • オリジンの負荷軽減
  • 番組表とかはCloudCDNで、プレイリストはアカマイで、キャッシュも色々分ける。
  • ターゲティング広告はユーザーのセグメントを分けて、CDNから配信している。

AbemaTVのオリジン監視システム「Procyon」

  • プロキヨンって読む
  • 独自の配信監視サーバーをつくっておられる。すごい。。。
  • 作った背景として、配信独自の障害監視が必要だった(サーバーはちゃんとしてるけど、動画が再生されないとか)
  • 動画の配信って大変だな、、、。

Kubernetes Jobによるバッチシステムのリソース最適化

  • AbemaTVのトランスコーダー
  • 動画トランスコードをバッチ処理してる。動画トランスコードは非常に計算量がかかる
  • でも、コンテンツ運用者の都合で、実行時間を短くして、早く配信できるようにすることがたまにあるらしい。大変だ。
  • なので、Fan-Outパターンで並列トランスコードしてくれる。初めて聞いた。
    • キューにタスクが積まれて、複数workerがそれを取り出して、並列トランスコードをしてくれる。
    • Goからキュー(redis)にタスクを入れる。キューの詳細情報はmongoに入れる。workerはkubernetes Nodeを使っている。
    • このworker(kubernetes Node)にもリソースを切り替えられる。しかし、リソースの無駄とかがあったので、それの整理を行ったとのこと。すごすぎ。
  • Priority Queueパターン
    • Fan outと違うのはキューが複数あるところ。良いところは、タスク割り当てるリソースを更に細かくできる。
    • でも、Fanoutよりしょっと複雑な構成になる。
  • Queuing Chainパターン???(聴き逃した)
    • Workflowエンジン??例:digdag, …etc
  • 上記で色々パターン考えたけど、Kubernetes Jobを採用
    • Jobのリトライ回数を制御できる
    • 並列実行の仕組みもあって、指定すればその数分のポッドができて、並列ジッコしてくれる(ポッドごとに別の動きをすることはできない)。なので、自前でそういうの作った。Job MBR ほにゃららってやつを。すご。完了動機なども
    • また、ジョブの監視の仕組みも自前っぽい
    • kubenetesの公式でも言っているらしく、単一ジョブを複数PODで実行しようとするとちょっと複雑になるらしい。

世界の動画技術動向を見据えたアベマの向かう先

正直、動画技術とか何もわからないから、ポカーン状態だったけど、世界はもっとすごくて、色々な動画技術があるんだな!って小並感満載のかんそうだけど本当にそうおもった。

  • 動画エバンジェリスト
  • 世界基準の動画技術動向を探しに行って、サービスの問題解決のヒントを探す人的
  • アメリカはコード・カッティングが進んでいる
  • Rokuってストリーミングデバイスもあるらしい
  • スイス政府は地上波放送廃止を決定したらしい。各国も流れに乗っているらしい
  • 動画ビジネスの敷居は結構低くなっているらしい
  • MAM(コンテンツ管理分野??)
    • メタデータ、コンテンツん紐づけ、ワークフロー、コンテンツ品質などのドメインごとのい管理が対象をわけると要素分解できる。
  • 世界的に海賊行為の拡大がある
    • 一応対策って色々あるらしい
  • DRMは必須
  • watermaking技術ってのが最近の注目らしい。コンテンツの流通経路が検知できるらしい。悪いことできない。
  • 費用対効果の高いコンテンツを作ろうとしてて、なんか良さそうな配信技術使ったり、、、、。なんか色々しようとしている。
  • 高解像度、大規模配信、低遅延、これらをすべてマックスにするのは難しいし、トレードオフの要素である。
  • UHD
  • エンコーディング最適化も色々あるらしくて、netflixがなんかすごいのを2015年に発表して革新的だったらしい。
  • QoE分野

.......あと、わかんない 😇


感想

  • 他社のインフラ構成見ると面白いし、勉強になる。ただインフラ知識が弱いので進出単語多すぎて、わかんないことが多かった。
  • 動画圧縮とか配信とかエンコードとか、その辺の話がぽかーん状態。
  • 聞く限り開発サイクルがどれも早いし、技術的にもハードな内容で、とりあえずスゲーという言葉しか思いつかんかった。
  • 後日の資料配布に期待

ペアプロならぬ、ペアデバックをやって良かった

とある機能の開発で、テスト環境でデバッグをしながら不具合の調査を行っていたのだけど、いまいち知識やら力やら色々不足しているのでなかなか解決できなかった。

slackにスレッド立てて、あーだこーだと独り言書いていたら、強いエンジニアの先輩が「一緒にデバックしてみてみますか?」と言ってくれて、解決とか頭の整理にもなってすごく有難かった。 プログラミングのみならず、やっぱり調査とかデバックとかでも色々ペアとかモブでやったほうが効率良さそうだし、勉強にもなるし、相手に説明することによって頭の整理にもなるし、なにより楽しい。

ペアプロとかを頼むタイミング、最近自分、遅いな〜‥

ただ個人的に悩みどころなのは、このペアプロとかモブプロとかペアデバックとかをお願いするタイミングが遅いのが良くないなと反省している。「もう少し調べたらわかるんじゃないか?」という頑張りたい欲とか、「あ、相手方が忙しそうだから、後でにしよう」という遠慮とかで、頼むタイミングを見失うことがある。まあ、後者は別に気にしすぎだから、とりあえず頼んでみて「あとでにして」って言われたら出直せばいいんだけど、問題は前者かなと思っていて、なんかいつも区切りを見失う。

一緒にデバックしてくれた先輩が以前「しばらく考えてわかんなかったら、すぐに聞いたほうがいいよ」が実践できてない証拠だと思い、改めようと思った。

intellij ideaとDashの連携が便利だった

Dashでリファレンス検索したりしてたのだけど、intellij ideaと連携できることを知って、RubyとかRailsとかのリファレンスに Cmd + shift + dで速攻探しに行けたので便利だった。 プラグインは以下からダウンロードして、intellijの設定画面から行う。

plugins.jetbrains.com

結構ググるときにqiitaとかブログの記事に目が行ってしまって、確実な情報である可能性が高い1次情報(公式リファレンスとか)を見るのには非常に便利。いちいちchromeで検索しに行かなくても済む。 あとsnippetを作っておけば、スニペットの下にUserのボタンが出てくるので、ポチッと押すとintellijの方にスニペットがペッと貼られる。コピペするという1アクションがなくなる(個人的にあんまり使ってないけど)

もっと理由を明記する心得

大した話ではないのだけど、最近レビューをしてもらうとき、「なぜこういうふうにしたのか理由もちゃんと書くと良さそう」というコメントを多くもらっている気がしていて、「あ、俺、質問とかされたときに理由が一部抜け落ちてたり、理由になってないことを理由にしてたりしてて、レビュワーも大変になってるじゃん」と反省した。

何を言ってんだ?って思うかもしれないが、これが自分の場合結構あるのだ。理由を明確にして回答したり、説明をしたり、文章を書いたりすれば、それだけコミュニケーションを節約できていいし、速につながるわけだ。 意識してなかったわけではないけれど、説明責任がうまくできていなかった感があった。

結構、文章とか説明を短く、簡潔にすることが良いことだ!という癖がついているのもある気がしていて、これは改める必要がありそう。具体的にどうすればいいのかは、ちょっとまだよくわかってないので、自分の中の宿題として覚えておきたかったのでブログにしたためた。