https://freee-tech-night.connpass.com/event/157012/

会計freeeのデプロイを10倍早くした話

北川修平 (shuheiktgw)

• 会計freee

• Phusion Passenger
  • https://www.phusionpassenger.com/
• Capistrano を使ったデプロイ
  • 問題点
    • 直列デプロイ
      • LBから１つづつ外してデプロイしている
    • 50分ちかくかかっている
  • 解決案
    • EKSへの移行
    • AutoScalingGroupを使ったBlue/Greenデプロイ
      • サーバー自体のプロビジョニングに４分ぐらいかかる
    • アプリケーションサーバー（unicorn）によるホットデプロイ
      • これを選択
      • デプロイ・ロールバックの時間が短くて済む
• アプリケーションサーバーの入れ替え
  • Phusion PassengerをUnicornにした
  • 安全に入れ替えるには
    • 影響範囲が大きい
    • プランBの確保
      • Blue/Greenを用意
    • 変更対象を深く理解する
      • ソースコードリーディング
      • 起動から陸セストをさばき始めるまでの流れ
      • USR2シグナルを受け取ったときの処理
      • 各パラメータの使われ方と影響範囲
• PreloadによるFileDDescriptorの共有
  • Linuxのfork処理の理解が必要
• 段階的リリース
  • テスト環境での負荷試験
    • 「負荷試験コトハジメ」
  • 他サービスでの先行リリース
  • 本番環境でのカナリアリリース
    • 2%程度
• Unicornへ移行した結果
  • 25〜30分かかっていたのが2〜3分に短縮
    • デプロイ数の増加
  • Redisまわりで一部問題があった
• FusionPassengerの有料版なら同じことできるが、サービス規模で試算したら高額だった

データの構造から再検討するパフォーマンスチューニング

久保卓也 (tkuboma)

• 会計freeeの中の話
• 監視
  • Mackrel
  • NewRelic
  • Monyog
    • DBリアルタイム監視に利用
  • Datadog
• Redashで見えるか
  • index効率、フルスキャンなど
• DBパフォーマンス改善
  • indexでチューニング
    • explainで地道に
    • インデックス追加したり、使うようにしたり
    • ActiveRecordのscopeに注意
    • indexを無駄にはらない
    • 検証は本番相当のデータで
  • クエリの変更でチューニング
    • 対象データのrowが多すぎる
      • 抽出条件の追加
    • クエリの結果が変わらないように注意
      • アプリケーション側で頑張る
  • データの持ちかたの見直し
    • idでなくstringでjoinしているテーブル
    • マスターデータとunionしている
      • マスターデータをコピーしてしまう
    • 頻繁にマスターデータが更新されるテーブルだと使えない
      • 設計でカバー
  • テーブル構成の見直し
    • 大量データを都度集計している
      • 集計テーブルを作成する
        • 圧縮率＝削減行数
    • ロック問題
      • 別トランザクションにして非同期実行する
        • Kinesis streamを利用
    • 集計テーブルのデータの切り方の設計重要
    • リアルタイム性の低下
    • 導入までのリードタイムが結構かかる
  • 機能の見直し
    • 必要以上に実行されていないか
      • Home画面とか
    • ビジネスサイドとのコミュニケーション必要
  • slaveへ逃がす
    • レプリケーションのラグに注意
    • 社内ライブラリを使用（OSSではない）
  • N+1の解消
    • bullet
  • Elasticsearch化

エンジニアがドメインロジックに集中するためのコアパッケージ整備

志賀誠 (@Maco_Tasu)

• コアパッケージ：各サービスで共通して使われるもの
  • ロガーやエラーとか
• マイクロサービス化でgoを使うことが多い
• マイクロサービス基盤にK8sを採用
• マイクロサービス化で各チームでそれぞれ作り込んでいて横連携ができていなかった
  • サービス基盤
• 全マイクロサービスのコードを読んで機能を洗い出す
  • goらしい作りになっているか
• デファクトとしてのパッケージ
  • 強制するものではない
• 拡張性
  • ダッグタイピング
  • go-cloud（CDK）を参考にした
• かんたんに組み込める
  • 依存関係
  • wire（DIツール）を使う
    • 依存の依存も解決してくれるのが良い
    • https://developers.freee.co.jp/entry/service-infra-and-wire
• 改善点
  • 早めに提供して改善ループをまわす
  • 使うことによる利点を伝える
• claat
  • チュートリアル作成ツール
  • https://github.com/googlecodelabs/tools/tree/master/claat

https://shuuu-mai.connpass.com/event/155130/

初参加。 エンジニアのキャリア、組織論についてお話いただく回とのことです。

きました pic.twitter.com/uRtdj6xWH2

— umemak (@umemak8) December 19, 2019

柱が邪魔でトークセッション見れない疑惑。

18:30 開場・受付開始

19:00~19:15 主催者からのご挨拶・当日のプログラムご案内

19:15~20:00 CTOトークセッション ※リアルタイム質疑応答あり！

株式会社SmartHR CTO 芹澤雅人氏

株式会社FiNC Technologies 代表取締役CTO 南野充則氏

株式会社クラウドワークス執行役員 兼 エンジニアリングDiv GM 飯田 意己氏

モデレーター 安尾 友佑 氏＊dely株式会社 サーバーサイドエンジニア

• なぜCTOになることを選んだのか
  • 南野：最初からそういう役割で参画した。
  • 芹澤：不可抗力的な感じ。VPoEから。VPoEになったのも不可抗力（前CTOの退職がきっかけ）。
  • 飯田：前CTOの退職がきっかけ。あえてCTOとは名乗っていない。
• どうやったらなれるのか
  • スタートアップに行けば不可抗力的になれる（笑）
  • 技術力だけではなく、ソフトスキルも必要。ビジネスとかマネジメントとか。
  • 経営も理解しないといけない。
• 今までの人生で一番影響を受けた本
  • 南野：「CEO」
    • 役職についてからどうあるべきかが書かれている
  • 芹澤：「ハッカーと画家」
    • 今でも通用する内容
    • ネットでも読める（？）
  • 飯田：「エンジニアリング組織論への招待」
• 良いエンジニアとはどんなエンジニアか
  • 南野：サボるのがうまいエンジニア
    • できるだけ楽に成果を上げる
  • 芹澤：課題にフォーカスした行動ができる
    • 技術は手段でしかない
  • 飯田：考えを表明できる
    • 周りを巻き込んでいく
• エンジニアの採用で見ているところ
  • 南野：マインド（価値観、こだわり）
    • ものづくりの原体験
    • ものをつくることを楽しめる
  • 芹澤：課題解決のプロセス
  • 飯田：結果よりプロセス
• エンジニアの評価について
  • 南野：行動指針の360度＋OKR
    • 評価が難しいと思ったことはない
    • エンジニアの人数比率が多いとやりやすい印象
  • 芹澤：OKR（半年ごと）
    • 成長につながる目標を設定する
    • 定性的な結果をどう評価するか
  • 飯田：MBO
    • 目標設定
• 今後エンジニアに求められることとは何なのか
  • 南野：技術、VPoE、プロダクト
    • テックリードとして。会社のどこを伸ばすのか。強みはなにか。そこに自分はどう関わるのか。どんな知識が必要なのか。
  • 芹澤：スペシャリストを目指すor浅く広くやるか
  • 飯田：責任を持てる範囲を広げていこう
    • 影響範囲を広げていく

20:00~20:15 スポンサー様ピッチ

CBcloud株式会社

• 物流系スタートアップ
• 課題
  • モノリス
  • toC向け

株式会社LegalForce

• 法律×テクノロジー
  • 契約書レビューシステム
    • アップロードすると、修正箇所と修正例を出してくれる

株式会社オープンエイト

• 素材から動画を生成する

freee株式会社

• 会社紹介

20:15~21:15 まつもとゆきひろ氏講演「エンジニア・キャリアアップ」

• 桜を見る会の招待もらった
• 「へびのように賢く、鳩のように素直であれ」
• Ruby開発までの話
  • バブル崩壊
  • 社内ツール開発からのチーム解散
  • 保守している間に作った
  • 自分のためのツール
  • クラスとインスタンスどっちが先問題
  • emacsのソースコードを一番参考にしていた
• 言語と思考の関係
  • サピア・ウォーフ仮説
    • 人々の思考は使っている言語に影響される
• へび
  • 自由であることとコントロール意識
  • 叱ると生産性60%低下
  • 叱られることはコントロールできていないこと
  • コントロール意識で生産性向上
  • 環境、未来は変えられないが、意識を変えることはできる
  • コントロールできないものと戦わない
  • 変えられないものは変えられない
  • 伝えないことは伝わらない、伝えたことも伝わらない
  • 諦めの気持ちが大事
  • 雨の予報は変えられないが、備えることはできる
  • 他人の態度もコントロール不能
    • 自分の受け止め方はコントロール可能
  • 「There must bu a reason」を３回唱える
  • できないことに心を傷めない
  • 未来予測
    • ソフトウェア開発者としては「上がり」のいちにいるので「現状維持」
    • Rubyが落ちぶれないようにする
    • できることに集中する
  • 「正解」もコントロールできない
  • 正解がある分野都内分野
    • ないぶんやで正解を追い求めることは無駄
    • 正解がないことを認める
  • 「浅く広く」と「深く狭く」は両立できない
• 鳩
  • 何が流行るかわからない
  • 運の要素
  • 未来予測に依存する判断を避ける
  • 判断基準
    • 実績、ライブラリ、相談できるヒトの有無・・・
    • 本能、勘
    • 「好き」な技術を
      • 外れても学ぶことはある
  • 本能や勘には自認が要る
    • 自分の興味、傾向を棚卸しする
    • 「好き」を知る
    • コネクティング・ドット
      • ３点→面
  • 「期待に応えない」
    • 勝手な期待
    • 外から来る動機は弱い。内からの動機は強い
    • 他人を動機にしない
    • 他人を制約にしない
• モチベーションの外部化はうまくいかない
• 後追いではないキャリアを
• 「鶏口牛後」の時代

21:15~21:25 アンケート回答/お写真撮影

21:25~21:55 懇親会 ※本物のシューマイ出します!!

22:00 完全撤収

今回はCMS回です。Webサイトの基本ともいえるCMS（コンテンツ・マネジメント・システム）におけるPWA活用法を学びましょう！

https://pwanight.connpass.com/event/156622/

きました pic.twitter.com/Fb0SO391qZ

— umemak (@umemak8) December 18, 2019

19:00 開場

19:20 挨拶&PWA Nightについて

• 2/1 PWA Night Confernce
  • タイムテーブル公開しました
  • LT応募これから
  • まだチケット買えるよ

19:30 自己紹介（全員）

• 本当に全員やった（持ち時間10秒）

19:40 microCMSとPWAで創るウェブ開発の未来

ウォンタ株式会社 松田承一（@shoma2da）さん

• https://speakerdeck.com/shoma2da/microcmstopwatechuang-ruuehukai-fa-falsewei-lai
• https://microcms.io/
• ヘッドレスCMS
  • 管理画面とDBを持って、出力はAPIを用意する
  • 全体ではなく、画面の1部のみCMS化できる
  • サイネージで使ったり
• 日本ではWPが強い（非ヘッドレス）
• 管理画面はReact/Reduxで使ったSPA
• インフラはAWS Amplify
• デモ
  • フォームの項目は管理画面で定義する
  • 「コンテンツ参照」が特徴的
  • 管理画面でAPIプレビュー（JSON表示）ができる
  • HTMLのtemplateタグ初めて見た
• 5Gでネイティブアプリのインストールが容易になったとき、PWAの立ち位置はどうなるか

20:00 WordPress と SSG で作る、情報発信サイト の JAMstack な PWA

lulzneko (ラルズネコ)さん

• WPは世界の30$のウェブページで使われている
  • WPで色々やろうとするとPHPの知識なりスキルが必要になってくる
• SSG(Static Site Generator)
  • ServerSideRenderingの対義
• JAMstack
  • JavaScript + API + Markup
  • パフォーマンス、コスト、スケーリング
  • セキュリティ
  • データとHTMLの分離
• こういう使い方をするならば、WPもヘッドレスと言える
• コンテンツ管理システムとしてのWPの強みを活かす
• WPの運用どうする問題
  • マネージドWPを使う

20:20 休憩

20:25 Firebase、Flamelink、Nuxt、Netlify、PWAを使ってJAMstackなブログを作る（仮）

みやおかさん

• https://slides.com/masayakazama/pwa-night-cms#/
• https://flamelink.io/
• ヘッドレスCMSはプレビューがないのが課題
• CSR with Prerendering
• 1年運用した感想
  • 開発者側は楽
  • 編集者側はいまいち
    • 管理画面使いづらい
• CMSのデモ
  • https://studio.design/ja
  • なんかすごい
  • 開発中

20:45 LT-1

hissyさん（5分）

• https://speakerdeck.com/hissy/introducing-concrete5-pwa-add-on-japanese
• concrete5 CMSのPWAアドオン
• 100ドルで試せる

LT-2

mercyさん（5分）

• https://www.slideshare.net/bitpart/pwa-night-vol11-20191218
• 「漢はコピペ」

21:05 懇親会

21:55 片付け

22:00 終了

https://techconference.yahoo.co.jp/2019_shibuya/?cpt_n=2019_shibuya_promo&cpt_m=web&cpt_s=passmarket

きました pic.twitter.com/mN83GXKkkn

— umemak (@umemak8) December 13, 2019

3年連続３回目の参加。 毎年会場が変わって、今年は渋谷です。表参道駅から歩きましたが。。

基調講演 13:00 - 13:45

藤門 千明 取締役 常務執行役員、CTO（チーフテクノロジーオフィサー）

• https://www.slideshare.net/techblogyahoo/yjtc19-in-shibuya-yjtc
• 「未来を、共に創ろう」
  • ユーザーアクションの最大化
  • オフラインにも進出（PayPay）
  • MUU5049万、MUB9302万, DR1132億
• 未来をす作るためになければならないもの
  • AI,データ
  • 価値を届けるスピードを大事にしている
    • 5年前は鈍化していた
    • モダナイゼーション
• 過去のモダナイゼーション
  • 失敗例
    • 2013年、アプリケーションライフサイクルマネジメントの実現
      • 常に最新のOS.HW・SWへ追従するための土台づくりが未完了
    • うまく行かない３つのレガシー
      • マインド、テクノロジー、習慣のモダナイゼーションを同時並行してすすめる
• マインドのモダナイゼーション
  • 2015年12月、決起集会を開催を２０００人集めて実施
  • 会場はここ（ベルサール渋谷ファースト）だった
  • トップからメッセージング
  • 自分ごと、オープン化、チャレンジ
  • 仮想化、CIのチャレンジが成功したのは、潜在的にエンジニアがいたから
• テクノロジーのモダナイゼーション

  • pic.twitter.com/0KKstVSH68

    Read more

https://bpstudy.connpass.com/event/152350/

野球系IT勉強会です。

LT18本＋始球式という、先日のgolang.tokyo LT大会を上回る本数。。 の予定でしたが、緊急登板回避が3名発生したため、始球式合わせて16本になりました。

きました pic.twitter.com/mzQj64wp4K

— umemak (@umemak8) December 10, 2019

感想：次回も参加したい。

始球式(18:44〜18:49) 2020年に向けて 中日ドラゴンズ与田剛監督へ1つの提言

佐藤治夫（Twitter: @haru860）

昨年12月の開催で中日ドラゴンズ与田新監督就任にあたり、2つの提言をさせていただきました。

https://golangtokyo.connpass.com/event/156678/

LT大会（１６本！）です。

19:00 ~ 開場・受付

きました pic.twitter.com/T9mR1MzOss

— umemak (@umemak8) December 4, 2019

19:30 ~ 19:40 オープニング・乾杯

• yappli

19:40 ~ 19:45 LT1: [仮]wire.goをプロダクトで使ってみた

bieshanさん

• DIツール
  • 依存関係のコードを生成してくれる
• wire使い方イマイチ理解していないので助かる
• 型を見て生成しているので、同じ定義だとどちらを使っていいか判断できない
  • 型の名前を変えれば良い
  • 内部まで書き換えに行く？
    • 構造体でラップしてあげれば良い

19:45 ~ 19:50 LT2: 作業効率アップ！便利なTUIツール5選

ゴリラさん

• https://speakerdeck.com/gorilla0513/zuo-ye-xiao-lu-atupu-osusumetuituru5xuan
• lazygit
• docui
• pst
• ff
• tson

19:50 ~ 19:55 LT3: Twitter を自由自在にフィルタリングする Twilter を作った

kawasin73さん

• tweetbotおすすめ
• フィルタした結果をRTするBOT
• 鍵垢（BOT）でRTしてそれをフォローしておく運用
  • 鍵垢じゃないとRTするたびに相手に通知が飛ぶ

20:00 ~ 20:05 LT5: go toolを使ってインライン展開をのぞいてみる(仮)

tutuzさん

• objdump（標準ツール）で逆アセンブリできる
• インライン展開しない場合の実行コスト
  • ５倍くらいになる場合もある
• 複雑なものは展開されない

20:05 ~ 20:10 LT6: Markdown内のコードだって美しくしたいんだ！！

po3rinさん

• https://speakerdeck.com/po3rin/i-want-to-make-the-code-in-markdown-beautiful
• mdを構文解析して処理している
• 舌打ちはアイデアになる

20:10 ~ 20:15 LT7: gRPC周りで困ったこととその解決方法

Go Sagawaさん

• https://docs.google.com/presentation/d/1bmTIrdgyi3E-bK3r7KHpsOFXDQOZoZVz6oXi7iSFPsw/edit#slide=id.g33148270ac_0_143
• protoの扱い
• 抽象化が難しい
• 構造化を考える
• clang-format でフォーマットできる
• 実装する前にレビューするの大事
• grpc-gatewayを使うと、ミドルウェアがかけるので良い

20:15 ~ 20:20 LT8: (仮)初めてGoで開発してみて思ったこと

rkmathiさん

• 言語使用や書き方はわかった、実際のアプリケーションはどう書くのか
• Gopher道場
• C++やRubyと比べて長短

20:30 ~ 20:35 LT9: [仮]keepAliveのすゝめ

Shogo_Tomiokaさん

• https://docs.google.com/presentation/d/10vwEqHnqL-woEmUYJ9Ei5jEouFiv02GgyqaMAVDo6pk/edit#slide=id.p1
• http.TansPortで設定できる
  • デフォルト有効
• tcnksm/go-httpstat
• res.Body.Close() しないと使い回せない
• パラメータはアプリケーションの特性を考えて調整する

20:16 ~ 20:26 休憩

20:35 ~ 20:40 LT10: マイクロサービスで共用するprivateなエラー&ロギングパッケージを作った

Shohei O.さん

• https://speakerdeck.com/shoheshohe/maikurosabisudegong-yong-suruprivatenaera-and-rogingupatukeziwozuo-tutahua
• ubarのzapでロギング
  • JSON形式で出力
• GOPRIVATE環境変数

20:40 ~ 20:45 LT11: gRPCのクライアントが絡むテスト

dice_zuさん

• https://daisuzu.github.io/golang-tokyo-28/#1
• DI
  • 3rbパーティ性のライブラリが辛い
• ダミーサーバー
  • コード量が増えて辛い
• リクエストレスポンスを記録再生する
  • cloud.google.com/go/rpcreplay
  • gRPCクライアントのシグネチャに縛りあり

20:45 ~ 20:50 LT12: Repositoryによる抽象化の理想と現実

sonatardさん

• https://speakerdeck.com/sonatard/ideal-and-reality-of-abstraction-by-repository
• 抽象化するためにRepositoryを使う
• 具象が変更したときに対応できる抽象化か？

20:50 ~ 20:55 LT13: インフラエンジニアもGolangが書きたい

nwiizoさん

• Python（Fabric）のSSHクライアントをGoにした話
• 運用が複雑化するとスクリプトも肥大化していく

20:55 ~ 21:00 LT14: 年末なのでgoを使ったプロダクトを初めてリリース・運用した1年を振り返ってみる

keitaro_1020さん

• https://speakerdeck.com/keitaro1020/nian-mo-nafalsedegowoshi-tutaapuriworirisusita1nian-wozhen-rifan-tutemiru
• スター数でライブラリ選定したら後で辛いことがあった
• 開発者のGo経験不足
  • Go有識者にソースコードレビューや勉強会を開催してもらった

21:00 ~ 21:05 LT15: Transform Go error handling using AST inspector

Hidetake Iwataさん

• https://speakerdeck.com/int128/rewrite-go-error-handling-using-ast-transformation
• ソースコードとASTの相互変換ができる
• ASTで呼び出す関数を置き換えてしまう

21:05 ~ 21:10 LT16: Go基礎力に効く標準ライブラリContext徹底理解。あなたはContextの挙動を説明できますか？

shibu_jpさん

• https://docs.google.com/presentation/d/1xglEURYptsTg5KXh4bxWVKKOPba7N5DwPvazdi6Q1HY/edit#slide=id.p
• Contextクイズ

19:55 ~ 20:00 LT4: Write Kubernetes Custom Controller in Go

morito_ikedaさん

• kubernetes-sigs/controller-runtime
• 割とかんたんにカスタムコントローラーが作成できる

21:10 ~ 21:35 懇親会

21:35 ~ 21:45 結果発表

21:45 ~ 21:55 終了・撤収

今回は 2019/11/18-21 で開催された KubeCon + CloudNativeCon North America 2019 の Recap 会だそうです。 どちらも参加していないのでどんな話が聞けるのか楽しみです。

https://k8sjp.connpass.com/event/155240/

きました pic.twitter.com/NkIGEmFehn

— umemak (@umemak8) December 3, 2019

18:15-19:15 受付開始

19:00-19:05 Opening (5min)

19:05-19:20 KubeCon + CloudNativeCon North America 2019 Overview

Ian Lewis (@IanMLewis), Google

• ２つのイベントが同時開催だった
• 次回登壇したいヒトは明日までCFP受付中
• 12000人くらい。去年は8000人くらいだった。
• 女性11%はDev系カンファレンスでは多い方
• 関連イベントたくさん（スライドに入り切らない）
• CNCF End User Community
  • 日本の企業もいくつかある（もっとある？
• Kubernetes Project Update
  • 1.16
  • Ephemeral Containers
  • 毎月3000人以上がコントリビュートしている

19:20-19:40 Your Path to Production Ready Kubernetes hosted by Weaveworks

土田 智大 (dullest), 楽天株式会社

• Co-located eventのひとつ
• Production Readyのために
  • Liveness/Readiness Probe
  • Configmap
  • FGraceful shutdown
  • Twelve-Factor App
• ハンズオン資料
  • https://tinyurl.com/kubecon-2019-workshop
  • https://www.weave.works/product/cloud/
• curlでスクリプト叩くだけでデプロイできる
• Gitのファイルをもとにする（GitOps）
• Production Ready Checklist

19:40-20:00 Keynote: Seamless Customer Experience at Walmart Stores Powered by Kubernetes@Edge

Junichi Yoshise (@jyoshise), Hewlett Packard Enterprise

• Walmartの決済の話
• POSシステムをクラウド化した（４年前）
• 通信コスト削減のためにエッジに処理を一部移動させる
• クラウドネイティブ化の動機
  • Dynamic deployment
  • Scalability
  • Resiliency
  • Observability
• エッジコンピューティングの動機
  • Low latency
  • Massive data
  • Privacy security
  • Local autonomy
  • Devices
• MEC(Mobile Edge Computing)
• データの同期
  • Edgeとクラウドで整合性が取れていないといけない
    • 商品の金額とか
• 物理的な制約
  • 各店舗にラックマウントサーバーを設置している
  • 基本的にEdge環境では、過酷な環境でメンテナンスフリーに近い形で稼働し続けなければならない
• K8sクラスタの更新
  • 遠隔地のクラスタ自体のデプロイを集中管理する仕組みが必要
• MECでは、端末は移動する前提
• スマートじゃないデバイスへの対応
  • KubeEdge
    • Device Twin
• アプリケーションのデプロイ
  • GitOpsが最適
  • WalmartはCDエンジンを自作
    • 今ならArgo flexやTectonが使える？
• Security
  • Secret管理
    • Vaultから撮ってきたsecretをetcdに一時的に保存するoperationを自作
    • クラウド側のみだとネットワーク切れたら使えなくなってしまうので

20:00-20:20 Running Apache Samza on Kubernetes - Weiqing Yang, LinkedIn Corporation

吉村翔太 (@yosshi_), NTT Communications

• samza
  • もともとはLinkedinが作ったストリーミング処理OSS
  • 似たものにSparkやFlinkがある
• 最近のHadoopの動向
  • オンプレで使う場合はディストリビューションを使う。主なものは３つ
  • ClouderaとHortonworksが統合。2021年くらい？
  • ClouderaDataPlatform
    • AWSをサポート。AzureとGCPも近々
• KafkaがHDFSなら、SamzaはMapReduceに当たる存在
  • KafkaもLinkedinが開発したOSS
  • Message queue, Message hub

20:25-20:55 懇親タイム sponsored by Yahoo! JAPAN

20:55-21:15 How Yelp Moved Security From the App to the Mesh with Envoy and OPA

鳥居隆史 (@ttorii0609), Dell EMC

• Security
  • K8s is NOT secure by default
    • 基本フルオープンなので、ザル。
    • 9個のプラクティス全部やれ
  • K8sのセキュリティは今アツい
• Open Policy Agent(OPA)
• mTLS
• OPAを使うにあたっての課題
  • OPA Policy Managerを作った
• セキュリティを考えるとサービスメッシュは必要
• Scope Creep
  • 要件がどんどん広がっていく様

21:15-21:35 The Release Team Shadow Program - Mentoring For the Future - Guinevere Saenger, GitHub & Lachlan Evenson, Microsoft

Yang Li (@idealhack), Kubernetes community

https://ochacafe.connpass.com/event/152768/

番外編の第１回。高可用性の話です。

きました pic.twitter.com/plY4jy7rsN

— umemak (@umemak8) November 29, 2019

18：30　受付開始　

19：00　オープニング

19：10　セッション開始

• https://speakerdeck.com/mmarukaw/oracleclouddekao-erugao-ke-yong-xing-akitekutiya
• データセンター電源障害の話から
• OCIはまだ日本に来てから日が浅いこともあり、大規模障害はまだない。
  • 海外ではあった
• Design For Failure
  • サーバーは落ちる前提で考える
  • クラウドベンダーの保証はSLAの範囲内まで
  • アプリケーションの最終責任はユーザーが負う
  • 高可用性のためのコストと複雑性を、軽減できるリスクに対してバランスを取る
• 高可用性とは
  • システムが継続して可動できる能力が高いこと
  • クラウドでもオンプレのときと考え方は同じ
  • クラウドの特性として高可用性を比較的低コストで実現できる
• 障害のレベル
  • 機器障害
    • プロセスだったりハードウェアだったり
  • サイト障害
    • DCレベル
  • 広域災害
    • 地域まるごと
• クラウドのリソースが備える特性を活かす
  • 本質的に堅牢なOCIリソース
    • オブジェクトストレージ
      • 耐障害性、安価、各種サービスとの連携
    • ロードバランサー
      • トラフィックの高可用性
      • サイトレベルの耐障害性
    • OKE(K8s)
      • クラスタとノードプールの自己回復
    • Exadata Cloud ServiceとAutonomous Database
      • Oracle Databaseの高可用性プラクティスが詰め込まれている
      • RACでスケール
    • OCI DNS
      • グローバルレベルの耐障害性
  • ユーザーに寄る高可用性実装を支援する
    • リソース配置
      • リージョン
      • 可用性ドメイン（AD）
        • データセンター
        • 東京はまだ１つなので、AZ障害イコールリージョン障害
        • データセンター間の通信は低レーテンシー
      • フォルト・ドメイン
        • DC内のサーバラック群をグループ化したもの
        • 仮想サーバーを別々の物理サーバーに配置したいときに有効
    • リソースの有効範囲
      • グローバル＞リージョン＞可用性ドメイン＞フォルト・ドメイン
      • リージョンレベルのリソース（VCN）でリージョンまたぎをしたいときはピアリングをする必要がある
      • リージョナルサブネットというのがある

19:43 10分休憩

ビール投入

https://yj-meetup.connpass.com/event/153658/

初参加です。

19:00 開場・受付開始

19:30 イントロ・乾杯

19:35 ヤフーのナビゲーション系のバックエンドサービスの課題をk8sで解決した話

高木 克彰(@tkgtransit) ◆ ヤフー株式会社

• ナビゲーション
  • マップの徒歩ナビ
  • 乗り換えナビ
• 従来のアーキテクチャ
  • エンジンデータはそれぞれ１台の仮想サーバーが担当
  • C++, Apacke Module
  • 課題
    • IFが異なるだけで基本ロジックはほぼ同じ
    • データ更新に半日
    • 脆弱性対応が多い、手作業
• 改善後
  • API層を統合
    • 社内PaaSに移行
  • エンジン層
    • 社内CaaSに移行
    • バイナリデータはinit comtainerで取得してオンメモリに展開
  • データの更新はk8sのcronで実行
• パイプラインはscrewdriver使っている

19:50 プライベートクラウドをk8sで刷新して良かった話

鶴田貴大 ◆ サイボウズ株式会社

• 自社製プライベートクラウド
  • OpenStackは使っていない
  • Ubuntu
    • 14.04から16.04へのアップグレードに２年くらいかかった
  • コンテナもほぼ使っていない
• インフラ刷新
  • necoプロジェクト
  • CKE(Cybozu Kubernetes Engine)
  • Certifiedになった
• 目的
  • 運用コスト低減
  • スケーラビリティ向上
• K8sを選んだ理由
  • 圧倒的に流行っていたから
• CoreOS採用
  • コンテナ用軽量OS
• GitOps
  • Argo CDを使用
• テナント
  • チームごとに権限を分離
  • ほかテナントに影響しないように
  • 単一のk8sクラスターですべてのテナントを賄っている
• 開発環境
  • クラスタを共同利用
    • うっかり壊すと大変
  • Kindに変更
    • ローカルPCでも動かせる
• Teleport
  • 多機能踏み台サーバー
  • ターミナルの入出力を録画できるので、監査に使える

20:10 PFNにおける二種類のKubernetesクラスタ

太田佳敬(@ota42y) ◆ Preferred Networks

• https://speakerdeck.com/ota42y/pfnniaru2tufalsekubernetes
• 自社GPUクラスタ
  • 機械学習のためにマシンリソースが必要
  • 2500以上
  • これの制御をk8sで行っている
• WebApplication用
  • aws EKSに構築
  • EKSを使うほどではないが、K8sを使い慣れているのでECSではなくEKS
• K8sのNetwork Isolation
  • 1つのクラスタに関係ないアプリが複数同居している
  • 相互通信しないようにネットワーク分離が重要
  • Network Policies
    • PodやNamespace単位で通信を制御できる標準機能
    • アプリケーションごとにNamespaceを分けて相互アクセスを禁止した
    • デフォルトでは通信許可設定なので設定忘れを抑制したい
      • Calicoを利用してデフォルトで通信禁止に設定
        • https://github.com/projectcalico/calico
        • Namespace内部の通信も禁止になるので、そこは許可する
        • kube-systemも許可する。禁止したままだとkube-dnsも使えなくなってしまう
        • orderで優先順位を決める
    • Network PolicyでALBを指定（許可）できない
      • Subnet構成で回避

20:30 小休憩

20:35 K8Sで画像PFを1年半運用してみた振り返り

山田 拓也 ◆ ヤフー株式会社

• 結論
  • 移行してよかった
• 旧システム
  • 社内VM
  • リカバリ手動
  • 障害で深夜対応・・

• 新システム

• 移行前のシステムを意識しすぎてしまった
  • サーバー構成など
    • Podとコンテナの配置どうする？
      • 一つにまとめてみた
        • 起動遅い
        • 管理も大変
      • 1コンテナ1Podにした
        • 迷ったらこれでOK
  • 監視設定
    • Grafanaの監視項目全部Prometheusに持っていった
      • Grafanaで良くない？
    • 監視の目的から見直す
      • 設定したしきい値も説明できないなら見直す
      • 物理やVMなら必須だった項目もK8sならいらない場合もある
• Prometheus
  • 予測で設定できる
  • 変化量でも見れる
  • Alertmanager便利

20:50 k8s初心者がgRPC × envoyを導入したら色々苦労した話

信原 有志 ◆ ヤフー株式会社

• サービスの課題
  • ドメインごとにチームが別れていて、それぞれ別の言語で開発していた
  • モノリス
  • 共通コンポーネントをチームごとに実装すると非効率
    • 共通コンポーネント配信システムを構築した
• 不具合
  • ローリングアップデート時のコネクションエラー
    • glaceful shutdownが正しく動いていない？
      • 負荷を下げて検証
        • 解決できず
    • IPテーブルの更新に遅延？
      • 検証しても解決できず
    • envoyのIPが更新されない？
      • ZipkinでTraceIDから照合して検証
        • これ
    • 対策
      • envoyでのgRPC health_checkの設定をちゃんとやる
      • nodejsアプリにも削除用のエントリポイントを追加
• 内部の動きをきちんと理解できていなかったのが原因

21:00 懇親会

22:00 終了

https://iij.connpass.com/event/151720/

https://eng-blog.iij.ad.jp/archives/4102

IIJmioでお世話になってます

2003年から毎年開催しているそうですが、初参加です。

インフラ周りはあまり直接触れることがないので、どこまで話についていけるか。

13:30 ~ 13:40 開会のご挨拶

IIJ 取締役 CTO 島上 純一

• 技術を通じてIIJを知ってもらいたい

13:40 ~ 14:20 講演1「安全なデジタル通貨流通を支えるアーキテクチャとエンジニアリング」

ディーカレット テクノロジーグループ マネージャ 河津 拓哉

• ブロックチェーンの話
• 価値の
  • 保管
  • 交換
  • 送受
• サービスアーキテクチャ
  • APIゲートウェイを挟んだマイクロサービス
  • 取引の部分が一番大きく、重要
  • 決済の部分はこのサービス独特なもの
• 認証まわり
  • OpenID Connect の実装
  • Two-way/TLS
  • Restrict(IP Based)
  • Traffic Policy
• 高信頼性（バックエンド）
  • サーバーの調達から自前で行う
  • 堅牢な設計、完全なコントロール
• 俊敏性（フロントエンド〜ゲートウェイ）
  • アジャイルな組織・手法で
  • 小さく・速く作ってフィードバックを回す
  • GCPを利用
• コンテナの話
  • ドメインの分割が一番難しい
  • latestタグやバージョン未指定でのパッケージアップデートはNG
  • rootユーザーでプロセスを起動させるのもNG
• k8s自前で管理するか
  • とても大変なのでマネージドサービスを使う
  • そうするとIaCが捗る

14:20 ~ 14:30 休憩

14:30 ~ 15:10 講演2「IIJのサーバインフラはここまでやっています」

IIJ 基盤エンジニアリング本部 システム技術部 基盤運営1課長 高畑 雅弘

• サービス基盤インフラNHN
• データセンターが抱える課題
  • コスト
    • 土地代が高い、狭い
  • ラックあたりの電力許容量が少ない
    • 建物自体の配電設計や空調も限界
    • 他のテナントと電気の取り合い
  • ラックの収容台数を最大化できない
    • ネットワークスイッチのポート数
  • 供給電力と空調能力のバランス
    • 詰めすぎると空調が追いつかない
      • サーバーファインが回って電力消費が増える
    • 空調に合わせると台数を増やせない
• コスト低減策
  • 設備投資
  • 運用コスト
• 土地・電気の問題を解決したデータセンターを作る
  • 土地・建物、電気、空調
• 事業者向けに最適化されたデータセンターを作る
  • データセンター開発部門とサーバインフラ開発部門が共同で検討
  • ラックの高さを増やせないか？
    • 日本国内では製造されていないが、海外ではある
  • サーバーをより多く搭載できないか？
  • 一度にたくさんのサーバーを納品できないか？
  • 奥行きの長いサーバーを搭載できないか？
    • 最近800mm超えるものがある
    • 配線など考えると1000mmでは足りない
  • ラック前のスペースが狭い
    • ラック設置後の取り出し作業などができなくなる
  • フリーアクセスフロア
    • 年月が進むとケーブルの地層ができてしまう
• 新しいサーバーインフラを作ろう
  • Open Compute Project(OCP)
    • ハードウェアのオープンソース化を推進している団体
    • 利点
      • 本当に必要なパーツのみで構成することができるので、調達コスト減、電力コスト減
      • 個別に機能を実装してもらえる可能性がある
      • 交換可能なパーツ交換に工具が不要
    • 欠点
      • 為替の影響を受ける
      • 専用ラックと電源が必要
      • テストは利用者側が実施する
      • 保守は自前でパーツ交換のみ
      • メーカーとのやり取りは英語や中国語
    • 調達コスト・消費電力ともに減

15:15 ~ 15:35 コーヒーブレイク

• 神楽坂「亀井堂」のパン

15:35 ~ 16:10 講演3「Untangling the world-wide mesh of undersea cables：世界に張り巡らされた海底ケーブルネットワークをひもとく」

IIJイノベーションインスティテュート（IIJ-II） 主任研究員 Zachary Bischof （ビショフ ザカリー）

• 海底ケーブルを使った通信は99%
• 障害が起きて孤立化することも
• なぜ今海底ケーブルの研究をしているか
  • ケーブルのEOL
  • 自然災害
• ケーブルが長くなれば事故のリスクも増える
• tracertではどの海底ケーブルを通っているかまではわからない
  • わかるようにしたい
    • ルーターの物理的な位置を特定する
    • RTTをもとに海底ケーブルを使っている可能性がある場所を推測する
    • 地上の距離を測る（Google map）
    • 過去のケーブルアクティビティデータをもとに推測する
  • こうすることで、どのケーブルが重要なのかが見えてくる
    • SEA-ME-WE3
      • https://www.submarinecablemap.com/#/submarine-cable/seamewe-3

16:10 ~ 16:20 休憩

16:20 ~ 17:00 講演4「セキュリティ動向2019」

IIJ セキュリティ本部長 齋藤 衛

• 標的型攻撃
  • 2003〜2008年頃は政府機関が対象、2011年以降に中小企業も狙われてきている
  • 暗号資産関連組織が狙われる
• ランサムウェア
  • 最近は検出数が減少傾向
  • ターゲットが絞り込まれている
    • 公共サービスや医療機関など身代金を払いそう（払わざるを得ない）なところ
• DDoS攻撃
  • SYN/ACK攻撃
    • 正常な通信との判別が難しい
  • 恐喝DDoS攻撃
    • 20〜30Gbps程度の攻撃でもネットワークによっては影響ある
• フェイクニュース
  • 正月のカニ
  • 本物の情報でも、順番を並べたりすることで受け取りての印象操作をすることができる
    • Facebookが実験した
  • マイクロターゲティング広告
    • ネット上の行動履歴など個人情報を詳細に分析できるようになってきている
  • ブレグジット問題
  • なにかの判断は原典にあたってから実施しよう

ここまでで家の用事のため撤収。データセンターの話面白かった。