デブサミ2019 2日目(02/15)メモ 17:25〜 エンジニア人生と定年退職、人生100年時代のエンジニアの生き方
主題が大きい
- ふわふわし過ぎ？
パラダイム(規範)
パラダイムシフト
- なんちゃら革命
- 一生に一度？
- 明治維新
- 敗戦
- 気付かない、知らない、ことがある
自己紹介(よしおかさん)
- 60歳
- 楽天にいた
人生100年時代
- ライフシフト
- ワークシフト
1970〜
- 1971 intel 4004
- マイクロプロセッサ
- よしおかさん中1
- 1975 BASIC
- エポックメイキングな事件
1977 Apple II, TRS-80, PET
- パソコン
- よしおかさん大1
- RSA public key
- ネット時代に生きる技術
- Cryptography
当時の情報ソース
- トラ技、サイエンス、bit、など
- 1977 ASCII創刊
- マイクロコンピュータ専門誌
- その前にIO
- 1971 intel 4004
1980〜
1990〜
2000〜
- 2000 ITバブル
- よしおかさんmiracle linux創業
- 2002 よしおかさん未踏
- 1年仕事しつつ研究
- 2004 FB, mixi, web2.0
- 2007 iPhone
- よしおかさんは過小評価していた
- 2008 勉強会ブーム
- 2009 bitcoin
- よしおかさんはピンとこなかった
- 2000 ITバブル
2010〜
- 2011 震災
- 2012 deep learning
2013 1000 speakers conference
就職、引退の感覚が変わる。
- 会場の受講者はほぼ会社員
- よしおかさんの話は会社員についての話
- 仕事感
- x 好き、楽しい、できる、やりたい
- y 時代の流れ
- パラメータ調整
- 物から情報へ
-
- 3年で4倍ぐらいのペースだった
- 性能向上に無頓着だった
- この法則を前提にしていた
- メモリを潤沢に使うプログラムでOKだった
- この法則を前提にしていた
- 最近は年3%ぐらいしか向上してない
- どうすんの？
- 簡単な性能向上はない？
- コア数が増えていった
- many core対応のプログラムを作らないといけなくなった
- どうすんの？
よしおかさんが学生になったきっかけ
- 201806 東大オープンハウス
- 201808入試
201809 退職＆入学
何故学生？
- 情報生産者になる
- パラダイムを疑う訓練
論文を読む読む読む→纏める→問題を見つける
学び直さないと色々陳腐化する
- 学び方を学ばないと
Be a hacker
- Make the world better
デブサミ2019 2日目(02/15)メモ 13:05〜 3周年に突入するAbemaTVの挑戦と苦悩
みゆっきさん
- コンテンツ配信チーム
- 趣味でも配信
新デバイス
- 赤い人はテックリード
- レビューしたり他メンバーからの質問を受け付けたり
- GCPを使っている
Java→Node→go
- goのパッケージ管理はgodep→dep
go本体のリリースサイクルが早い(半年)
マイクロサービス
- 80個ぐらい
- コンテナ化
機能毎のリリース
共通ロジックをどう管理するか？
負担の大きいサービスを分解する
GKE
mongo DB
cache
terraform
- GCPの構成管理
packer
- マシンイメージ管理
- GCEインスタンスのディスクイメージ作成
- マシンイメージ管理
ネットワーク
CI/CD
- codeship
- バックエンド
- テスト
- イメージ作成
- バックエンド
- deploykun
- 社内製ツール
- ChatOps
- PR→codeship→GKE
- codeship
モニタリング
- bugsnag
- Google Cloud Monitoring
- 異常検知
- slack
- エンジニアにコール
- 担当外の人にコールが行ったり
- pagerduty
- インシデント管理
- 画像が貼れない
ログ
メトリクス
- staticdriver
- redis, mongoDB
- prometheus
- アプリ
- grafana
- staticdriver
今後
挑戦と苦悩
- 規模拡大
- キャパ、マネジメント
- 安定化
- 老朽化
- ミドルのEOL
- 古いアーキ
- 規模拡大
目指すアーキ
- 配信レイヤーの全二重化
- ユーザーの直前まで二重になっているべき
- チャンネル別リソース
- オートスケール
- 過去の実績に基づいてスケール
- 配信レイヤーの全二重化
デブサミ2019 2日目(02/15)メモ 11:05〜 CI/CDを使い倒して数段上のソフトウェア開発をしよう！
スライド https://speakerdeck.com/kimh/cdwoshi-idao-siteshu-duan-shang-falsesohutoueakai-fa-wosiyou
CI/CD戦国時代
- 何故関心が高まっている？
- 「ビシっと」答えられるという人はいなかった(受講者の中に)
CODEZINEの連載がキッカケ
- 「CI/CD」でぐぐるとトップに出てくる
Circle CI Japan
- 日本語サポート
- 問い合わせがあまり来ない？
- 日本語サポート
Hop-on!
- 金さん個人運営
テスト
- コンピュータにやらせよう
- テストを自動実行するのがCI
- テストの信頼性がない
- し忘れ
- テストが壊れている
- 壊れを検知
- 直さないとマージできない
- 修正を強制する
- 環境依存
- 変更を検知
使われない自動化は壊れていく(サイボウズ)
環境依存
- False Negative
- コンテナを使う
- LXCのコンテナでテストしていたのでCircleCIが有名になった
テストの新陳代謝を高める
Why Not
CI/CDツールのメンテナンス
- jenkinsおじさん問題
- CI/CDツールのプロがプロジェクトに1人だけ
- その人が抜けるとCI/CDが機能しなくなる
- クラウド型がおすすめ
- 導入しやすく、運用コストが低い。
- jenkinsおじさん問題
CD
- Dはデリバリー？デプロイメント？
- デリバリーは人の医師が介在する
- デプロイメントは全自動
- デリバリーの進化系がデプロイメント
- 広義のデリバリーの定義も存在する
- ビジネスの価値を継続的に〜
- デプロイは配置するだけ
- リリースは配置してトラフィックを受ける状態にすること
- Dはデリバリー？デプロイメント？
リリース後の問題
- フィードバックループ
- 細かい単位でリリースする
- フィードバックを早めに得る
- CI無しでは回らない
- No CI, No Feedback Loop
- フィードバックループ
Why Not CD?
CircleCI内の事例
- AWS上にビルドマシン200台
- 1人が半日張り付いて入れ替えが終わる
- 新旧コードが混在
- docker, kubenetes導入
- マイクロサービス化
- 1年かかった
- AWS上にビルドマシン200台
Beyond CD
未来
- 自動化することで進化してきた
- 今何を手動でしているか？
- 設定、モニタリング、デプロイ環境構築
- 今何を手動でしているか？
- first commitからクライマックスになる？
- 自動化することで進化してきた
ユーザーコミュニティ
- 3/5 メルカリオフィス
- 4月福岡
デブサミ2019 2日目(02/15)メモ 10:00〜 ドラゴンクエストXを支える失敗事例
- 個人スポンサー席満席？
- 立ち見あり
開始前にコンドーさん(翔泳社)の挨拶
- 2日続けて参加してる人がそこそこ多い
スクエニ青山さん
オンラインサービスはリリース後が本番
- 運用、運営
良い設計
- 要件を満たしているのが前提
- 経験からくる
DQ10は6年半やってる
- 痛い目見ないとわからない部分もある
組織によって解は違う
-
- MOとの対比→MOはホスト(ロビー？)あり
詳細は本見てね
運営、運用が重要
- 運営→攻め→イベントとか→柔軟性
- 運用→守り→不具合対応とか→継続性
失敗事例
その1 スキル(?)を使った時の効果音が鳴り続けたり、ノイズがある「場合がある」。
redmineを使っている
その2 パーティーのオートマッチングが行われない「場合がある」
- 邪神の迷宮(?) 8人パーティーで進めるダンジョン
- エリアが複数あり、エリアによってマッチングに参加できる条件が異なる。
- 条件は月2回(?)自動で更新(変更)される
- プログラマ、デザイナー、プランナーがいて、条件はプランナーが決めている。(って言ってたと思う。うろ覚え)
- 条件判定はクライアントで一次チェックが行われてからサーバーで最終チェックしている
- 一次チェックがOKで最終チェックがNGだった
- サーバー側にハードコードされた条件判定処理があった
- 以前のアップデートで条件のデータフォーマット変更があった
- リリースタイミングが微妙だったので、一旦暫定対処としてハードコードした。
- 該当ダンジョンのデータが新フォーマットで、システムがまだ旧フォーマット対応だった？
- リリースタイミングが微妙だったので、一旦暫定対処としてハードコードした。
- 以前のアップデートで条件のデータフォーマット変更があった
- 教訓
- 暫定対応は本対応するまでチケットを残そう
その3 釣りで釣った魚(魚じゃないのもある)のサイズ誤判定
- 釣れるものは123種類
- 釣りの処理はC++とLuaで実装されている
- 1023mm以上だとビッグサイズ、1022mm以下だとノーマルサイズ。
- Lua部分で1000で割ってmをmmにする処理の誤差で1023mmのものが1022mmと誤判定されてた
- 割る前に補正処理が入っていたけど割るところでNG
- ぱっと見であってそうだったからスルーしてしまった
- 急に起きた
- データ作るところで1023mmになるはずのものが1022mmになってしまった
- ダブルマスタ(再計算を避ける為にマスタデータを複数持っていた)のズレ
- 別の不具合も影響して起きた
- データ作るところで1023mmになるはずのものが1022mmになってしまった
- Lua部分で1000で割ってmをmmにする処理の誤差で1023mmのものが1022mmと誤判定されてた
- 魚(?)を交換してしまった人をログ等から探して個別に対応した(スクリプトでデータ修正)
- 教訓
- 表面化していないバグがあるものと思え
考察
- 影響範囲を明確に
- ちゃんとチケットを登録してクローズまで持っていく
- どうやったら防げたか？
- チケットを登録していないものが大部分
- 影響ないだろうと軽視しがち
- チケットを登録していないものが大部分
- チケット200000ぐらい(不具合以外のタスクも含めて)
QA
- 開発体制はどれくらいの人数でやっている？
- 具体的な数字の公表はNG
- 人事から止められている(コスト等がバレてしまう？)
- スタッフロールには数百名の名前が
- 具体的な数字の公表はNG
- 影響範囲を特定する方法は？
- 個別に見る
- 個々の経験値に依存(あまり良くない)
- チケットに登録されない理由は？
- (担当者が)登録するまでもないと思ってしまう
- 勘違い
- 大部分はできているがたまーに漏れてしまう感じ
- タスクが多い中、モチベはどう保つ？
- 飽きて辞める人もいる
- チーム内の異動はある
- 開発体制はどれくらいの人数でやっている？
雑感
- ゲーム固有の話は少なめで一般的な話が主だったかなぁという印象
20180809
台風
- 夜のうちに北に抜けたみたいで、今朝は雨も降らず電車もなんともなかった。
お仕事
headにOGPのmetaタグ書いてて、試しにfacebookのdebuggerでチェックしたらfb:app_idが必須とか言われた。
- そのアプリIDのおかげで、facebook側でどれだけシェアされたかみたいなのが見られるらしい？
- シェアされた時の見た目を変えたいだけなんだけどな
AWS LambdaのあるfunctionだけRDS接続でaccess deniedになった。
- serverless.ymlのfunction個別のiamRoleStatementsにRDSのARNが入ってなかったせいみたい？
- function全体に設定するiamRoleStatementsにはRDSのARNは書いてあるんだけど、function個別の設定で上書きされちゃうってことなんだろうか？
スタバ
- 抹茶のフラペが出てたんで飲んでみた
- つぶつぶなものの食感が良かったかな
- 桃のフラペを最終日に滑り込みで飲みに行ったんだけどまだあった
グラブル
- ラブライブコラボは一応maniacも100hellも食えてる
- スタレ前半はシロウ
