y.takky てくめも

web技術について勉強会の参加メモだったり、本を読んだメモだったりを載せる予定

宅内LANの障害切り分け

ZoomでMTG中に接続が切れてしまう。という現象があった。 とりあえず電源抜いて、つけるということをしたがまた発症したので原因を切り分けた。

1.プロバイダか?

  • とりあえずtwitter見た感じ障害情報なし
  • NTT自体の場合、リモートワーク中の他のメンバーも障害が起きているはずだがそういう現象もなし。

なので原因は自宅のネットワークと仮定

2. デバイス固有の問題か?

なので、デバイス固有の問題では無いと判断

3. Wifiのみの問題か?

  • PS4,デスクトップPCを有線接続しているが、どちらとも不通だったのでルーターから先がおかしいと判断

4. ONUルーター

  • ルーター自体に接続して管理画面に入れればONUが怪しい
  • 今回は管理画面自体に入れなかったのでルーターが怪しいと判断
  • 本当は別のルータを入れたり、ONUから直接続すれば断定はできるはずだが、そこまでもやるのが面倒だったのでルーターと判断

というわけで、新しいルータを買ったとさ 痛い出費だ...

ゆるゲーマーのリモートワーク環境

前書き

昨今のコロナウイルスの影響によりリモートワークが推奨されるようになった。
私の働いている会社でも原則リモートワークになったのだが、私はゲーマーだったので特に準備もなく快適にリモートワークができたという話をする。
また、普通の人は部屋にないのか..みたいな知見があったのでそれも合わせてまとめる。
なお、ゲームをやってる関係上配線がカオスになってるので実環境の写真はない

前提

PCはMacBookPro13-inch で Thunderbolt 3 portx2のタイプを利用している PCおよびUSB-C Digital AV Multiportアダプタ は貸与品

モニター1

KG270

リンクは並行輸入品で値段が高かくなってしまっている。 購入時は2万円付近だった気がする。
FPSをやる関係上応答速度が速いモニターが欲しくて購入したもの。 応答速度は1ms。
入力端子はHDMIx2ポート.D-SUBと取り回しがしやすい。 27インチとFPSをやるにしても作業用にしても大きすぎず小さすぎずでちょうどいい。

配線

HDMI ポート 2には、HDMI Switcher(GREEN HOUSE製秋葉で3000円ぐらいのもの)を接続して、 任天堂Switch,MacBook,私物DeskTopを切り替えて接続できるようにしている。 MacBookProからは usb-typec →HDMIケーブルを利用して接続している。
これ。

HDMIポート 1には、PS4を直結 D-SUBは Thunderbolt→Dsub変換を使い、私物MacBookに接続している

モニター台

メーカーは忘れてしまった。ヨドバシで買ったもの。 USBポートは付いているが、使ってない。 モニターを置いた状態でちょうどよい目線の高さになり、目線を下げればMacBookのモニターが見えるという状態

モニター2

GL2460

amazonのリンクは後継のGL2480

2014年に買ったモニターで6年ぐらいサブモニターとして利用している。
反応速度は5msとゲーム用途にはあまりよくないが、安い。
作業用のサブモニターとしては十分に役立つ。
基本的にターミナルかSlackはこちらの画面に映している。

入力端子はHDMIx1,DVI-1,Dsub-1

配線

HDMIは1ポートしかないためHDMI Switcherを接続している MacBookProからは

www.apple.com

を利用してHDMI接続している。
あとは、私物のDeskTopPCをHDMIに繋げて切り替えて使っている。

モニターアーム

このモニターは

を利用している。
机の上にプリンター台を置いている関係上モニターそのままだと高さが微妙で高さ調整をしたかったので、モニターアームを購入
なお、プリンター台には小物を置いていて本来の用途には使えていない

このキャビネットがないタイプを購入。
商品自体はかなりしっかりしているが、部屋の大きさに対してちょっと大きすぎたなぁという印象。
横幅自体は150cmぐらいあればモニター2台置いても余裕だけど、L字部分は完全に物置になってるだけであまり有効活用できてない。
利点はPCと飲み物を完全に分離できるので飲み物を倒した時の事故は防げる。
しかしこのくらいならば、サイドデスクを買ったほうがよさそう

あとモニター台+ MacBookをおくとキーボードを置くスペースが取れないので 奥行きはもう少しあったほうがよさそう

椅子

ゲーミングチェア欲しかったけど、うーん普通の椅子で良いかなという感じ。
そのままだと腰が痛いので、

をたまに利用している。

ヘッドセット

SENNHISERのGSP 107を使っている。

付属品で、3pin→4pin変換が付いている(がそれがどこかに行ったので別のものを買った) これでMacのイヤホン端子に接続している。 同僚曰く一番音声がクリアらしい

キーボード

REALFORCE for Macを使っている。

これは今回のリモートワークにかこつけて買ったもの。
キーの打鍵感とか素晴らしい。
HHKBも良かったが購入まで時間がかかりそうなのと打鍵感などが試せなかったので断念。

Magic TrackPad2

www.apple.com

職場で使ってる人がいて、良さそうだなぁと思って買ったけど使いこなせなくて死蔵してたやつ。
机の奥行き上MacBookのキーボードの上に、RealForceをおく必要があって、自ずとMacのTrackPadが使えないから使っている。

その他

デスクライト

これは前職で照明の反射が気になって手元を照らすために買ったやつ。 就寝前の読書用に使っていたが、夕方など電気つけるまでもないなぁみたいな時に役立つ

イヤーマフ

集中したいときや隣の部屋がうるさいときなど

フットレスト

買った直後は足元がごちゃごちゃしていて、微妙だったけど椅子の高さや足元のデスクトップPCの配置を変えたりしたら良さそうだなと思ってきた。
購入して1-2週間なので様子見

と、リモートワーク 後に買ったものもあるが、モニター、机、椅子、ネット回線はゲーマーだからこそ準備できていたものだと思う。
というより一般の人は家に机や椅子ない感じなのか... どういう家具配置してるんだろ。

AWSソリューションアーキテクト模擬

この本の模擬をやった。 AWS自体は業務で触ったりしてたけど、ほぼ無勉に近い。

20/30なのでこのまま本試験受けると多分落ちるやつ。

間違った問題

S3の静的ホスティングの問題

  • S3エンドポイントはVPC特にプライベートサブネットからS3にアクセスすることができる機能のこと

IAMの問題

  • EC2インスタンスに紐づけることができるのはIAMグループではなくIAMロール

EBS最適化

  • EBS最適化オプションはEC2の通常のネットワーク帯域とEBSアクセス用の帯域を別々にするオプション

ネットワーク設計 インターネットゲートウェイに関する設問

  • インターネットゲートウェイはマネージドサービスなので可用性は担保される
  • VPC無内の通信はローカルにルーティング、それ以外はIGW経由でインターネットに出る。

インメモリキャッシュ

  • CloudFrontはCDNなのでキャッシュとは違う
  • Lambda@Edgeはユーザに近いリージョンでLambdaを実行するもの
  • ElasticCache for Memcachedは揮発性がある。
  • ElasticCache for Redisは永続化可能

監査の問題

  • CloudTrailでマネジメントコンソール上の操作の監視ができる
  • CloudWatch Logs でCloudTrailが出力したログを引っ掛けることで、検知ができる

セキュリティーグループとネットワークACLについて

  • セキュリティーグループは、ステートフルなので、インバウンド通信が許可された場合、戻りのトラフィックに関しては阿吽とバウンドのルールは関係しない
  • ネットワークACLはステートレスなので、インバウンド・アウトバウンドどちらの許可もないと通信ができない
  • セキュリティーグループはEC2インスタンスを対象とするもの
  • ネットワークACLはサブネット全体の通信に関するもの

Elastic Beanstalkについて

SES

  • メール受信もできる
  • マネジメントサービスだから冗長性や可用性について利用者側が意識する必要がない
    • とは思うんだけど、バウンスレートが多いと利用止められるし、利用者側が意識する必要があるような気もする。冗長性はともかく可用性って面で。

S3の特徴

  • イレブンナインは可用性ではなく、耐久性

まとめ

  • あまり意識することがなかったIAMやネットワーク周りは勉強する必要がありそう
  • Elastic Beanstalkは使ったことないんでここも勉強が必要
  • あとはEBSとかもちょっと見ないとなぁ。

オープンソースで実現するログ分析技術入門

connpass.com

ログ分析におけるElasticStackの勘所

www.slideshare.net

※ESはver7.0

時系列データの勘所

  • 時刻情報を持つイベントデータ(ログ/メトリックス) , 時刻データが大事
  • logstashやBeatsから取り込んだ時系列データは自動的にローテートしてくれる(indexの肥大化を防ぐ、ただしUTC)

セキュリティにおけるログとは

  • フォレンジック調査
  • ハンティング業務(驚異を見つけるために主体的に見に行く)
  • 監査
  • 監視業務

ElasticStack

  • Kibana+elasticsearch+(beats+logstash)

beats

  • beats family
  • metricsをとるならmetricbeatのような感じ
  • ちなみにgoで書かれている

logstash

  • beatsで取り込んだものの加工
  • DB接続

beatsとlogstash

  • beatsはagent投入してelastic stackへ投げるようなもの 軽量
  • logstashはソースとフィルタが多様

  • 機械学習したいならElastic Cloudがいいかも

  • AWS ES
  • Open Distro for ES

Elasticsearchの設計

  • nodeの役割がいろいろある。兼務もできるし専用ノードでもいける
  • メモリとストレージの設計において JVM Heapを効率良くできるかがポイント

全文検索と時系列データの違い

  • 全文検索はcache上にのこるか。がポイント
  • 時系列はwritecacheの方がおおいはず。 なのでread cacheには乗らないのでDiskから読むようになる。
  • なのでDiskのI/O性能が大切

  • スキーマ定義は?

    • やったほうがいい。stringで格納されるので分析したいのが正しく分析できなくなる

Elastic SIEMってのがでたよ

  • OSSじゃないけどBasicなので無料で使える

ETL

parseとenrich

  • parse: csvをパースする
  • enrich IPをhostにしたり、 blackリストのIPであればflag立てたり
  • ログの加工はいろいろ流派ある。
    • ログ自体を加工する
    • logstashで加工する (前処理
    • elasticsearchで引っ張ってきたデータをあとから加工する(後処理
  • plugin作るか、rubyfilter書くか

  • ESにつっこめなかったのはDeadLetterQueueにファイルとして突っ込める。 これをLogstashで再取り込みする

  • logstashのfingerprint filterで一位になるようなIDを生成してdocument_idで突っ込む

Molochではじめるネットワークフォレンジック

ネットワークフォレンジック

  • ネットワークログ = パケットデータの情報収集・侵入検知など

パケットキャプチャ

  • エンドポイントでキャプチャする
  • ミラーリングしてネットワーク経路上でキャプチャする

課題

Moloch

  • OSSのフルパケットキャプチャツール Molochが収集解析, ESがメタデータ管理/検索
  • Moloch 1.8.0 が最新版 5.x or 6.0

splunk→ ElasticStackで芽生えたなにか

  • 用途に応じて複数存在しているログ分析システムを統合するかどうか
  • AWS上でElasticStack環境を構築して、オンプレミス環境からログを転送する構成とした。
  • 各パイプラインごとにLogStashをFargate上にデプロイしている。
  • 外はEC2運用
  • オンプレからS3へログ転送 するLogStashと実際にESに入れるLogStashがある。

    問題

  • Logstashのinput s3はスケールアウトできない
  • S3に入っているデータをQueueに突っ込んだりするのは別にする必要がある

まとめ

  • 時系列データで性能を出そうとするとインフラコストかかる
  • 長期データはあまり向かないかも?

AbemaTV Developer CONFERENCE 2018

だいたい一ヶ月前だけど AbemaTV Developer CONFERENCE 2018にいってきた。

AbemaTV Developer Conference 2018

これも2016-2017と連続で参加していた。

ytacky.hatenablog.com

ytacky.hatenablog.com

今回の開場は渋谷に新しくできた渋谷ストリーム グーグルの日本法人も六本木からここへ移転するみたい。

あとはメモなので

Keynote】 AbemaTVのエンジニア組織論と今後の技術的戦略

  • MAUがだいたい1,100万ぐらい
  • 中途採用が2006, 新卒採用開始が2008年ぐらいから
  • エンジニア組織的には1000人ぐらい

求められる3つの開発力

  • product
  • quality : ザッピング時のUXのクオリティー
  • technology : テクノロジードリブンで開発していく

組織論について

  • 施策自体は当たり前のものだけど組織のカルチャーや時流によって入れていくことが大事
  • 全体のKRから分解していってOKRを導入した。
  • 横軸でTechTeamをおいている
  • グレード制 上位のエンジニアが評価する
  • 目標設定: HRBrainを導入。目標のオープン化
  • 同じグレードで目線合わせ、上位グレードへの目線上げ
  • キャリブレーション : 評価のすり合わせ
  • 成長機会 : input/outputの後押しをしている

  • Management -- 組織成果を最大化する -- TechLead15人に対してエンジニア51人。 TechLead育成を勧めている

  • チーム全員でひねり出して案を出す

バイス戦略

技術的戦略

  • AbemaTVの初期開発はだいたい4ヶ月ぐらい
  • チケット駆動開発で職種でトピックを分離、優先度定義されたチケットが降りてきてやれるだけやる
  • スタンドプレイの最大化になっている

  • GCPを有効活用した。ロギング,LB,コンテナマネジメント

  • 機能開発にフルコミットするように
  • CDNAkamai 動画配信に最適化

  • 配信構成の見直しをしなくちゃなーと思うように(亀田興毅事件)

  • Encoder->配信システムの遅延やパケットロス zixiを定常運用化

  • 技術ドメインを抽出してチーム化した。

  • どこに責務を負うかという観点で。

  • プロダクト開発に集中できるようにオンコール対応などを受ける。

A1「72時間ホンネテレビ」の負荷対策とその裏側

  • 技術本部 : CAのメディア事業を社内横断的に見る人。
  • エンジニアブログ委員長など
  • Developer Blogであとから情報は公開する

キックオフに向けて

対策内容

CDNでのキャッシュ

 - プレイリストをCDNキャッシュ
 - Web用をCloudCDNに対応させた
 - キャッシュヒット率を向上させた

リクエストのポーリング間隔調整

 - 視聴数やコメント数の部分

別系のシステムへ

 - スパイクしやすいトラッキング用のリクエスト
 - プライベートクラウドからAWSへ

負荷試験/サーバ台数の調整

 - 去年のDevConで発表あったやつ

負荷対策が間に合わない部分

  • エラーハンドリングの見直し
  • メンテナンスへ入れられるように
  • 間に合わない機能を使ってもらわないように

リリースをしてもアップデートが

  • 強制アップデートの仕組みがあったので..

カウントダウンするだけの直前番組

  • 起動処理にはリクエストが多くて、負荷をさげるため
  • オフロード率99.8%だったのでCDNでほとんど返せた

エスカレーションのレベルとアクションを規定しておいた

Future

  • インターネットは多くの人が見れば見るほど混雑する
  • ISPCDNなどの制約も TBps自体には必要となってくるう

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

仮開局まで

- 収録番組の配信がマスト

技術選定

 - オンプレはコスト以外のメリットがなかった
 - なぜGCPを選んだか
      - Googleが使っているのと同じようなL7LB 
      - GKE/k8s
      - ネットワーク帯域に対するコストの安さ
           - AWSはマシンのスペックに応じてネットワーク帯域が決まっている
           - GCPはその制約がなかった
      - StackDriver Logging / BQ
      - 台湾リージョンしかなかった
           - 日本<-->台湾間のインジェストの安定性が問題
           - 台湾<-->東京に移行する人的リソースが避けない

   - 言語 Java -> Node.JS -> Golangへ
   - 編成ツールを完成する必要がありMongoDBを愛用

アーキテクチャ

 - Microservices
 - コンテナ化でリソースの有効活用
 - gRPC+Protocol Buffers
 - Gateway系/Backend系に分けたGateway Pattern

番組表

 - スナップショットをGCSから取得する
       - 編成途中の番組表がユーザに表示されるのを防ぐ
      - バージョン管理しとくことで実機確認ができる

仮開局〜本開局

  • 生番組/広告/コメントができることがマスト

広告

  • abemaTVの広告局が用意したAdサーバと連携
  • 予めトランスコードされた動画セグメントをGCSから取得して配信
  • ターゲティング広告
    • CMをパースなライズできる設計だった

本開局後

動画セグメントのキャッシュ

  • GCSがSPOF
  • GCSへの一時的なスループットの低下
  • Redisキャッシュつかった

ログ改善

  • fluentdを使っていたがGolandで使いにくい
  • GcloudPub/Sub + BQ

-- 各ゲートウェイでPub/Subにログを流してバッチサービスがBQにInsertする。 -- ログ解析チームがSubscribeすることが可能

メトリクスの可視化

  • Stackdriver Monitoringを使用
  • 各リソースを可視化したい
  • Prometheus+Grafana

年末年始の対応

  • 広告サーバからのレスポンスをキャッシュ
  • Redis Clusterをスケールアウト
  • 1/1に検証して1/2にバージョンアップを実施 redis-trib.rb 3.06にバグがったので

1周年~2周年

配信の安定化

RTMPでCMキューを入れていたが切れるとCM入れられないのでHTTPで

障害時に何をしていたか

  • アラートのOnCallを受け取ったが根本原因をさぐるのに時間を用意した mongosが詰まっていたので再起動で解決した

データストアの分離

  • 単一データストから各ドメインごとに分離した

24hホンネTV

  • エンジニアが出演情報を知ったのは、一般と同じ9月
  • CDNの利用。 番組データ/番組表 CDN

2周年〜現在

  • ターゲティング広告を開始
  • ユーザをいくつかのセグメントに分けてセグメントごとにプレイリスト配信
  • 安定稼働を取るように

とここで腰の痛みでリタイア。 最近カンファレンス言っても腰痛くて早めに帰ってしまうのがあれなところ。 年かな..

2018年4月に転職してました

2014年に新卒でエンジニアとして入社した会社を 2018年3月末で退職し 2018年4月からいわゆる Saasビジネスを行っている会社にWebエンジニアとして転職してました。

何をやってたの?

ハンドルネームでググると前職のテックブログの記事が出てくると思います。 主に、Webエンジニアとして2-3年間 新規メディア開発したり改修案件してました。

後半の1年ではSREとして主にGCP/GKE周りの導入をしたりしてました。 特にGCP関係では、 コミュニティであるGCPUGのSlackに入り浸ったり勉強会に参加してました。 GCP/GKE周りでも1-2回発表ができたのである程度コミュニティへの還元ができたんじゃないかなと思ってます。 それでも、早い段階からGCP/GKE周りを触っていた割にはあまり還元できてなかったのかなと思ってたりするのでもう少しやってればよかったなと思います。

なんでやめたの?

理由はいろいろありすぎるので私を知っている方は飲みにでも行きましょう。

主には、自社メディアなのに受託開発案件がちょくちょくはいってきてあれ?ってなったのと、
あまり戦略もなく新規メディア構築してその後放置しているみたいなのが結構増えてきてあれ?ってなったのがメインですね。
やっぱり自分が作ったものが使われないと悲しい。

なんでこのタイミングで書いたの

なんだかんだ言っても前職のエンジニアの人たちはリスペクトしていて、流石にすぐ書くのはなぁと思っていたからです。
特に新卒の頃からのメンターの方にはいつもお世話になっていて彼がいなければ今の私のエンジニアとしての生き方はなかったなと思っています。 あと台風で暇だったから。

転職活動どうしてたの?

転職ドラフトでお声がけ頂いた会社を何社か受けたり、エージェント経由で応募したりって感じでした。
10月末に活動を初めて12月中には決まってた感じですね。

今何しているの?

また webエンジニアに戻りました。 Sass系のWebアプリケーション開発をしています。 go書いたり Vue+nuxt.jsでフロントエンド周りちょっと書いたりしています。

例のあれ

偉い人がこういう記事には貼れって言ってたやつ

Amazon.co.jp

GDG DevFest Tokyo 2018 メモ

今年もGDG DevFest Tokyoに参加してきた。 gdg-tokyo.connpass.com

2016から毎年行っているらしい。

ytacky.hatenablog.com ytacky.hatenablog.com

今年は新宿だったので、かなり行きやすかった。

DialogflowとCloudFunctionsで作るGoogleアシスタントアクション

@flatfish

t.co

Googleアシスタントアクションの話

  • コミュニティプログラムってのがあって、アクションをリリースするといろいろもらえたりする

開発する3つの方法

  • Actions SDK
  • Dialogflow
  • テンプレート
    • NonCodingで作れる。SpreadSheetを埋める感じ

Dialogflow

  • LineやSlackなどにも
  • アナリティクス機能
  • SDKが豊富

  • Dialogflowは聞き出すところまでできる

  • それ以降のバックエンドはできない。計算とか

Intent

  • 会話を開始する文(トリガー)を決める
  • 会話を成立させるための条件を決める
  • 作成したことのない謎の Intent
  • Default Fallback Intent
    • アクションが失敗したときのIntent
  • Welcome Intent
    • アクションが成功したときのIntent

      Entity

  • いわゆるメニュー1つ1つ。
  • Key-Value方式

Fulfillment

  • サーバにjsonを飛ばすことができる

acitons-on-google-nodejsライブラリ

  • DialogFlowではjsonを渡すのでよしなに処理してくれる

TIps

  • YoutubeのGoogleDevelopersチャネル
  • AoG公式Docs
  • Slack

Container

Kuma

  • コンテナ(物理)はなにがいいのか。
  • 統一規格なので何でも運べる

(ソフトウェアエンジニア的な)コンテナ

  • 統一された規格
  • どこでも動かすことができる
  • 環境が隔離されている

だいたいコンテナを使っている人は会場だと90%ぐらい?

Prod環境でコンテナを使う利点

  • 使い捨てが簡単
  • 増やすのも簡単
  • 減らすのも簡単

  • アプリケーションの依存性を内包できる

    • もしchefやansibleなどでマシン自体をスケールアウトしたらどちらが責任を持つか
    • コンテナの中と外で責任の分離ができる

注意点

  • 一度コンテナを作ったらそのコンテナの中をいじらない (immutable)
    • いわゆるコンテナにSSHしたら負けなやつ
  • コンテナの中にデータを保存しない (stateless)
    • ロードバランシングして画像がない方に振り分けられると見えない
  • コンテナの管理・運用
    • Monitoring,Orchestration などなど

InGCP

  • Kubernetes Engine
    • ちなみにkubernetesを使っている人は会場の中で10%以下ぐらい?
    • kubernetesの説明があったが割愛
      • コンテナのオーケストレーションツールで、水平スケールや自動ヒーリング、サービスディスカバリとロードバランシングなど。
      • Node-poolの提供 Nodeをまとめて管理する概念と、Nodeのスケール機能
      • GCPの連携
  • StackDriver
    • LoggingやTracing,profilling,Alertingなどモニタリングする際のツール
  • Container Registry
    • DockerHubみたいな
  • Cloud Build
    • コンテナのビルドとワークフローの指定管理を行うツール

GCPで作るデータ処理パイプライン

@orefon

t.co

  • バッチとストリーム処理の概要と問題

データ処理の分類

  • バッチ処理
    • 有限の範囲のデータを扱う
  • ストリーム処理
    • 処理対象となるデータの範囲が無限で時々集計する必要がある

機械学習の特徴量生成の場合

  • 時系列系の特徴量
    • リアルタイムレコメンド

GCP上ではプログラミングモデルとインフラを提供している

  • プログラミングモデル

    • ApacheBeam
    • Dataflow,Sparkなど
    • Javaが一番揃ってるけどPython,Goも
  • 分散実行インフラ

    • フルマネージドでオートスケール
    • GCP各種ストレージと連携できる
  • Cloud Dataflow+beam

    • データの処理と分析を担う
  • Cloud Dataprep -UI上でできる非プログラマ向け
  • Cloud Dataproc + Hadoop
    • Hadoopをそのまま移行する感じ

Apache Beam

  • データの処理の流れを宣言的に記述する
  • 抽出データ(PCollection)を処理(PTransform)でつないでグラフを作る

Google Cloud Dataflow

  • Apache Beamの実行環境
  • オートスケール

まとめ

  • ApacheBeamはバッチ処理とストリーム閭里を簡易に記述するプログラミングモデル
  • Dataflow使うと早く安く処理できる

Firebase Realtime Database in Production

speakerdeck.com

AI メッセンジャー

B2Bのチャットサービスの提供、自然言語処理を含めて自社製 FIreBase:アプリケーションインフラの提供サービス WebSocketの管理をしたくなかった

なぜ書き込みをサーバからしか行わないか(直接クライアントから返さないか)

  • フィルターなどが弱い(RealTime Database)
  • BigTable等の別Storageから検索・フィルタリングできる。 ただし、データの分散や二重管理などが必要になるので、構成の吟味が必要

Filtering values

  • FireBaseは値のクエリが苦手
  • 設計時点でフィルタリングが必要なかったりしやすいように設計すべき

How to manage incidents

  • Lineともつなげていて、絶対落とせない。証券会社とかあるし。
  • FireBaseに障害が起きってるっぽいときには、Pollingに切り替えて Restでやるようにした。
  • データをロストすることもあり得るので、全データはStackDriverにログを出力しておく

Future works

  • 最終的にFireStoreかな。まだ検証はしてないけど
  • Double Write以上になりそう。

感想

  • AoG面白い個人的にやってきたい感じはあるんだけど、マネタイズのイメージがまだつかなくて企業導入はまだまだな感じ
  • コンテナ自体は使っているけどKubernetesを使ってる人はまだまだ多くないようだ。
  • CloudDataflowあたりはまだそんなに使ってるところ多くないのかな。セッションは人気だった。
  • FireBaseが結構本番での利用事例が出てきた感じ