Hejdaの見る夢

一人前のエンジニアを目指して頑張ったこととかをつらつら書くブログ

最近見た映画memo 2018/10

個人メモ 映画 DVD

DVD

  • パシフィック・リム: アップライジング ( https://pacificrim.jp/ )

  • ジグソウ：ソウ・レガシー ( http://jigsaw.asmik-ace.co.jp/ )

    • 本作「ソウ」シリーズのジグソウが死んで10年後のお話し
    • 1作目が好きな方は好きかも?
    • まあ、懐かしむ映画です

  • KUBO クボ　二本の弦の秘密 ( https://gaga.ne.jp/kubo/ )

    • 全編クレイアニメなことや、第89回アカデミー賞で長編アニメーション部門にノミネートされたことで話題になった作品
    • ストーリーもちゃんと伏線を回収していて良いし、何よりクレイアニメだとは思えないほどのクオリティ
    • この作品はまた観たいし、本当におすすめです 💕

  • パラノーマルアクティビティ ( https://www.amazon.co.jp/dp/B002UHJ9GC )

    • 2007年に公開され、その後いろんな派生を出すほどには有名な作品
    • この映画のDVDにはある特典映像があり、それがとてもおすすめ
    • その特典とは、「稲川淳二と観るパラノーマルアクティビティ」
    • 映画を観つつ、稲川淳二がワイプで解説兼語りをするんですが、
      • 途中から自分の幽霊怪談話を始めちゃう(本作は悪魔のお話)
      • ワイプが逆転しちゃう(稲川淳二がメインで、映画がワイプ)
      • 本作のラストを勝手に先に予想しちゃう(しかも外れている)
      • 自分は専門家では無いと言い始める(そして、また自分の幽霊怪談話が始まる)
      • 見事な顔芸w(笑える)
    • 等など、とてもつっこみの多い特典映像なので、自分は何を観ているんだろうという錯覚を覚えます
    • とても…怖いですねw

builderscon 2018 2日目 に行ってきた時の個人メモ

個人メモ 勉強会

日時・場所

Azure をエンタープライズ環境で利用するためのアンチパターン・ベストプラクティス

  • 説明
  • 発表者
    • @tsubasaxZZZ
  • Azureで構築・運用するワークロードの整理
    • Azureで使えるサービスかどうか確認する
    • CPUコア数とメモリの組み合わせを自由に変更不可
    • 等々
  • 一番大切なこと
    • 三原則
      • 人は必ずミスをする
      • ソフトウェアはバグがある
      • ハードウェアは壊れる
    • 障害・メンテに強いシステムが作れるかが重要
  • 閉域網を使ってAzureへ接続する方法
    • ExpressRouteを使用する
      • 閉域網はネットワークサービスプロバイダーが提供(IIJ, イクイニクス等)
      • 経路がきっちりわかるので責任の範囲が明確になる
    • BGPを利用したルーティング
      • ルーティングとNATを意識する
      • Expessrouteを活用する場合はBGPの知識は必須
      • ルータのスペックの検討も必要
  • サブスクリプション・アカウント管理の方法
    • Azureを使うためにはアカウントが必要
    • Azureのアカウントの管理が必要
      • RBAC(IAM)はちゃんと設計する
      • 場当たり的に作ると後が大変
    • Azure AD B2Bによる招待
      • 他のテナントのユーザを招待する
    • サブスクリプションの管理
  • エンタープライズ環境でAzureをうまくつかうポイント
    • 活用するためのカルチャーを作る
    • とにかく手を動かく(検証する)
    • 困ったときはサポートに聞く　
    • 障害・メンテに強いシステムを作りましょう!!

あなたの知らないデータベースのロギングの世界

  • 説明
  • 発表者
    • @hfm
    • GMO Pepabo, 技術部プラットフォームの人
  • なぜ監査が重要か
    • 「カラーミーショップにおける情報流出」事件がきっかけ
    • なにか起きてからでは遅い
      • 追跡可能性の低下
        • 流された後なので
        • まずはサービスの復旧がメイン
      • 検知の難易度情報
        • そもそもクエリが流れた時点で気づくべき
      • 回復力(復旧、事業の回復)の低下
    • フェーズ
      • 抑止・抑制
      • 予防・防止
      • 検知・追跡
      • 回復・継続
    • 監査ログの強化
      • 不正プログラムによどDBへのアクセス
      • 「いつ・誰が・どこに、どのようなクエリを発行したのか」は見たときしか分からない
      • 不正プログラムはずっと同じとは限らない
  • 監査ログに求める情報
    • SQLステートメント(クエリ)
    • クライアントIP
    • クライアントユーザ
    • 接続データベース名
    • 接続先ホスト名
  • 監査ログは完全性が必要
    • 抜けがあったら意味が無い
    • 失敗したクエリも必要
    • クエリになっていないものも重要
    • DBに届いたすべてのコマンドが重要
      • 攻撃の可能性
  • 監査ログをとる情報
    • ログの形
  • ProxySQLとは
  • ProxySQLを介した構成
    • ログはバイナリ形式
      • デコード必須
    • DBサーバのIOやディスクの懸念は無くなるけど…
    • ProxySQL ClusterというProxySQLの冗長構成が出来るのでやりたい…
  • ProxySQLハマりどころ(中間層を挟むと大変だよねって話)
    • ユーザ管理問題
      • ProxySQLはバックエンドのDBにつなぐアカウント情報を自分に保持
        • DBのユーザ・パスワードに変更があると、ProxySQL側にも入れないといけない
        • エラーログもわかりにくい
    • charset問題
      • --skip-character-set-client-handshakeをサポートしていない
      • ProxySQLにもdefault charsetがある
      • 結果、ujisとか文字化けする
      • 基本的にはクライアントで頑張るしか無い
    • Multiplexing

  • 今後の展望

    • 監査ログの活用
    • 不正クエリとは
      • サービスによってまちまちなので考える
      • 明らかにおかしいものもある
        • WHERE句の無い SELECT* 等

  • 質疑応答

    • L4で見たら？
      • アプリケーションの悪さは分かるかもしれないけど、SSLは中身見れないね
      • tcpdump...
    • アプリケーションログで分かる?
      • ログは一箇所でとればいいわけではないので複数でとるの良い

なぜエンジニアはパフォーマンス計測しないのか

Webアプリケーションエンジニアが知るべきDNSの基本

  • 説明
  • 発表者
    • @mamy1326
  • 資料
  • 言葉の定義
  • ドメイン名とIPアドレスを関連づける　〜名前解決〜
  • 名前空間の構造　〜ツリー構造とゾーン〜
  • ︎DNSの応答はどんなもの？　〜リソースレコード〜
    • 名前解決の応答として返す実際の内容であるリソースレコードの代表的な物を解説します。
  • 名前解決にリソースレコードで答える　〜権威DNSサーバ〜
    • クライアントからの問い合わせに答える
    • リソースレコードを提供、管理する
    • 名前解決ができなくても応答を返す
    • 世界に13集団（クラスタ）！
  • ブラウザからどう名前解決するの？　〜スタブリゾルバ とフルリゾルバ〜
    • ブラウザ(アプリケーションやメーラー)から名前解決依頼、スタブリゾルバ
    • スタブリゾルバから再帰検索、フルリゾルバ
    • フルリゾルバから反復検索の流れ
    • リソースレコードのキャッシュとTTL
  • AWSでドメイン名を扱ってみるデモ　〜ドメイン名をWebサーバに関連付ける〜
    • あらかじめ取得したドメイン名を使い、実際にAWSでサービスするまでのDNSの操作をデモ
    • NSレコード、Aレコード、CNAME、Alias（Route53独自機能、便利）の解説
    • TTL、親の権威DNSサーバ、子（自分）の権威DNSサーバ、サブドメインの設定
    • 10分ほどで順を追って設定し、ドメイン名からWebサイトがみれる
    • 実際の意味を知って操作をみていただくことで、安心して操作できる！
  • キャッシュを制する！　〜キャッシュとTTL〜
    • TTLとは
    • TTL、キャッシュを正しく扱う
    • どこにキャッシュされる？
  • トラブル事例：権威DNSサーバ引っ越しトラブルと正しい手順
    • 引っ越しトラブル！新しいネームサーバが引けない！
    • 手順1：新しいサーバの構築
    • 手順2：引っ越し先の権威DNSサーバ構築
    • 手順3：親の権威DNSサーバの委任情報切り替え
    • 手順4：引っ越し元のゾーン情報切り替え
    • 手順5：平行運用
    • 手順6：古いネームサーバの停止
  • 浸透問題〜なぜ浸透と言ってはいけないのか〜
    • 浸透という言葉の意味とDNSの仕組みの決定的な違い
      • 浸透のイメージ
        • 変更をトリガーにして、変更したもの以外に変更が及んでいく。というイメージ = puth型のイメージ
      • 実際の名前サーバ
        • 取得側がトリガーとなるpull型
      • 間違った言葉・表現を使っているため
    • TTL、キャッシュ、移転
    • 正しい知識と手順の理解が大前提
    • しかし我々にはクライアントがいる
    • 経験上での解説例
    • エンジニアリングとは寄り添うこと

1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム

  • 説明
  • 発表者
    • @mogetta
  • 今回の話
    • CircleCIの話
  • 背景
  • k8sのデメリット
    • 構造が複雑
    • Dockerしかサポートしていない
    • 小規模サービスにはtoomutchでは??
  • Nomad
  • Scheduler
    • タスクをスケジューリングする
    • Cluster Managerとかともいわれる
    • 種類
  • Namadのアーキテクチャ
    • サーバクライアント
    • マルチリージョン・マルチスケール
  • CircleCI2.0について　
    • LXC + 自前ツールの限界
      • LXCつらい
    • Nomadを選んだ理由
      • 自分たちのプロダクトと相性が良かった
      • batch jobにフォーカス
      • CircleCIでは単発のジョブがたくさんある
      • 1ビルド = 1Nomad Job
      • k8sさ差０ビス管理フォーカス
    • Nomad以外
      • k8sは上述
      • Mesosは情報が少なく、複雑。
      • Docker Swarmは出たばかり
  • CircleCIは1.0から2.0になって爆速になった件
    • 1.0
      • SSHでリモートコマンドを実行(同期的)
      • 大量にSSHセッションが増えるので詰まる
    • 2.0
      • gRPCに変更(非同期)
  • 実際にサービス運用してみてわかったこと
    • Single Binaryファイル
      • メリット
        • 開発環境でも簡単にテスト出来る
        • 運用が楽
        • スケールが簡単
    • Nomadは、まだβ版だけど安定している
      • CircleCIでは障害に出くわしていない(例外有り)
    • より少ないAWSのインスタンスでインフラを運用出来る
    • 誰も使ってない
  • 運用ノウハウ
    • スケールアップ
      • Consul AgentとNomad Clientが入ったマシンを起動するだけなので便利
      • スケールアップが簡単
      • スケールダウンの際はDrainモードが必要
        • CircleCIのサービス上、問題だった。
        • 自分達でパッチを当てた
    • Declaring Bankruptcy
      • GCの負荷により使いなくなる
      • すべてのnodeで強制的に削除する
      • CircleCIでジョブが終わった直後にGCを削除
    • Nomad Server on k8s

builderscon 2018 1日目 に行ってきた時の個人メモ

個人メモ 勉強会

日時・場所

産業でガチ利用されるRaspberry Piの話

  • 説明
  • 発表者
  • アジェンダ
    • IoTの光の話
  • Raspberry Pi(=raspi)を産業利用で選ぶのか
    • 高い品質
      • 世界ナンバーワンの製造数(当社比)
      • 他社とは製造数で雲泥の差
      • 最近はSONY工場でも作ってる(もともとはSONY UKが作ってる)
    • 安価
      • raspi日本だと4000円くらい
      • 他社は5万円くらい…
    • 汎用的な開発環境
      • デフォがDebian
      • CPUがARMだけど、最近はARM用ビルドも増えてるので問題はあまり無い
    • 安定供給
      • 製造数的に問題無さそう
      • 互換ボードも出てきた
        • eg. ASUSのTinker-Board
  • 弊社でのRaspberry Pi採用の実績
    • 実製品のプロトタイミング
      • raspiで試作して、本番へ
      • Golang使ってる
    • 組み込み製品のデバック用途
      • CIを回すことも出来る
        • Gtihub + Jenkins + Slack
    • 工場での出荷(のためのチェック)ツール
      • 小型で安価なチェック機材が作れる
      • 治具祭り
      • 出荷前の最終チェックとしてansibleを使ってチェックしている
        • 最終的に、ansible経由でアクセス出来ないようにして完了
    • IoTゲートウェイ
      • 最初は品質に懐疑的だった
      • 以下の実績がすでにあった
        • 工場ツール
        • 負荷試験もOK
        • raspi3bからBLE対応したので、原価削減(Wi-Fi、BLEドングルが必要無くなる)
  • 手軽に使えるRaspberry Piのソースコードを交えた利用例
  • より強固なデバイスにするための基板拡張とそれを支えるソフトウェア技術
  • それでもRaspberry Piではだめな場合はどうするか？
    • 構成
      • Node
        • noble
        • express
      • 通信
    • ログ
      • 基本的にはwebサーバと一緒
      • 違う点
        • 容量が少ないので削除は頻繁に
        • I/Oの上限がある
        • 日時でクラウドにアップロード
    • セキュリティについて
      • SDカードを使う以上は中身を抜かれる
      • 大事な情報はSDではなく、拡張基盤(nRF52)にいれる
      • ソースコードの暗号化
      • OSは最新に保つ
      • 仕様として、ゲートウェイ起因でクリティカルな処理が実行出来ないようにしておく
      • 外部検査機関でチェックする
      • ソフトウェアのアップデート
        • apt経由でアップデートする
  • それでもRaspberry Piではだめな場合はどうするか？
  • 他、Raspberry Piの利便性を高める方法や、安全に使うためのノウハウなど
    • 4000円すら高い時
      • コンシューマ用途
      • BLEだけでいいならnRF52がおすすめ
      • BLEとWiFi使いたいなら…
    • 電池駆動させたい
    • セキュリティ的
      • 組み込み系は大抵の場合、外からのアクセスを防ぐ仕組みがある
      • 破壊 = 製品の破壊 なので、あまり意識していない
    • 罠
      • Non-OSのコンボチップはWi-Fi5GHzに対応していない
  • 質疑応答
    • 使用するSDカードは品質のチェックは必須
    • 再利用性を考えて、SDカードは抜き差し可能な状態にしていている(レンタル事業のため)
    • 次回のraspiに求めているのは、ハード面で追加・改善
    • 5GHz必須の時はtoBの時。闇のお話。
    • SDカードの耐久試験 = Write試験
    • raspi0はtoB向けだと信頼性とコストで選択肢から外れている。toCなら可能性あるかも。
    • SDカードはT社が良い

Caching at Netflix: The Evolution of EVCache

Webサービスにて200週連続で新機能をリリースする舞台裏

実録！ある担当者がみた「謎ガジェット」開発１年史

Webサービスの品質とは何か？アラート地獄と監視の失敗、サービスレベル目標設計から学んだ3つの答え

  • 説明
  • 発表者
  • 後に資料公開する予定
    • WIP
    • 立ち見だったので資料を見るメイン
  • 監視
    • 普段は意識されないもの
    • 障害発生時に意識されるもの
    • 辛い
  • webアプリケーションの監視の技術トレンド
    • サーバの見方が「ペット」から「家畜」へ
    • 監視サービスの充実
      • インテグレーションも充実
      • 監視サービスの監視からの開放(Zabbix重いよね問題)
  • アラートあるある
    • 本当に異常なのかわからない
      • エンドユーザにとってどう損害なのか
    • アラートが行動に結びつかない
      • 一時対応
      • 今、対応するべき障害か分からない
      • とりあえず動かない
        • アラートなってるけど、webブラウザで見ると、(遅いけど)動くケース
      • 常に異常
        • 毎日、定期的にアラートが出ている
        • ずっとエラー出てる…
      • 何も出来ない
    • ただしい方向にむかっているのか分からない
      • 闇雲にやってもなにも分からない
  • そもそも監視は
    • エンドユーザへの品質担保
    • 監視はその手段である
  • 監視がうまく動いていないと
    • 開発生産性が下がる
    • 会社全体の士気が下がる
  • MTTR
    • Mean Time To Repair
    • 平均復旧時間
  • MTBF

ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか 〜その原因と対策〜

  • 説明

  • 発表者

  • 話すこと

    • スマホアプリでゲームが動く仕組み　
    • 開発と運用チームの体制について
    • リリースから現在までに起きた問題を対策対応
  • アジェンダ
    • ゲームの仕組み
    • ゲーム制作チームとプロジェクト
    • その他は上記と一緒
  • ゲームの開発に関して
    • 開発運営チーム
      • たくさんの役割の人がいる
      • イメージ的には中規模の会社
    • コストの話
      • 開発期間は2-3年
      • その間にかかるコストは投資
      • リリースしてから回収出来るようになる
      • 初期開発費の回収
    • アプリの構成
      • スマホアプリ
      • アプリ内で保存管理するデータ
      • API
      • リアルタイム通信
    • ゲーム特有のサーバ事情
      • 予測を結果
      • 構成要素と複雑さ
      • クライントアプリ
      • 施策とアクセス状況の関係
  • 負荷の対策と原因
    • リリース時に起きたもの
      • リリースまでに多くのチェックポイントがある
      • αテスト/βテスト
      • 予測流入数とそれを耐えられるように負荷試験
      • フェイルオーバー試験
      • QA(インゲーム/アウトゲーム/課金試験)
      • 運用演習(リリース/データ更新)
    • ログに関して
      • ログ集約はサービスに即座に影響が出るとこでは無いので、リリース後に後手後手に回る傾向がある
    • マルチプレイの罠
      • リアルタイムサーバを介して通信
      • photon を使ってる
      • Redisでkeysを使うと死ぬ
        • Redisはシングルプロセス
        • keysは総なめのコマンド
        • 対策として、setを使う
      • βテストではマルチプライのテストが出来てなかったので分からなかった
    • クライアントに仕組まれたバグ
      • 事前準備はしたけど、リリース後にAPIが重い…
      • 全ユーザ情報をとってくるAPIを頻繁に叩かれている
        • 本当は最初の1回だけで、後は差分更新のはず
        • クライアント制作チームの認識のズレ
      • アプリのバージョンアップの時間は無い
        • APIを研ぎ澄ますしかなかった
  • まとめ
    • ソーシャルゲームは想定外のことが多い
    • 障害を完全防ぐことは不可能
    • 想定外の自体も受け入れる
    • 過渡に神経質にならない

builderscon 2018 前夜祭 に行ってきた時の個人メモ

個人メモ 勉強会

日時・場所

uzulla: 乾杯＆ウェアラブル謎ガジェット

cho45: 自作 BLE キーボードのその後

kazuph: IoT開発の闇

f:id:nari_kyu:20180907133228g:plain

KAYAC hara: 人類バーチャル化のすすめ

ペパボ Make部: デモ〇〇連発 〜夏の終わりの打ち上げ花火〜

  • 説明
  • ぺぱぼMAKE部
    • GMOペパボ社員による非公式のものづくり部活動
    • ほとんどがゆーれー部員
    • MakerFaireにも出店
    • 社内展示会
  • IoTでどんなものを作ってきたのか
    • ロボットボールの作り方
      • ロボットボールを触ってみたいという衝動
      • 光るは正義
      • omicro
    • omicro
      • https://medium.com/tichise/ロボティックボール-liveballを作った-7185b45f6e88
      • 球体の中のラジコン
      • bluetooth -> iOSアプリ -> omicro
      • マイコン
        • mbed
          • LPC1768
          • LPC114FN28
          • LPC**
        • mbedの良さ
          • オンラインIDEがある
          • ライブラリが豊富
          • コマンドツールが使える
      • watch OSアプリも作っている
        • 手の甲の動作で動くのは展示では良い
        • 予期せぬ動作もある
      • BLE
        • koshianを使用
      • ボディ
  • IoT歯ブラシスタンド
    • 原因
      • 口内環境は大事
      • 歯ブラシの交換時期が分からない
      • 歯磨きを計測して、口内環境を管理したい
    • マーケ
      • 「歯ブラシ」と「IoT」はたくさんある
      • 「歯ブラシスタンド」と「IoT」は前例が無かった
    • 工程
      • アイデアづくり
      • 雑なプロトタイプを作る
        • 圧力センサー
        • ESP32
        • 昇圧3.3V DC
        • Arduino IDE
      • 実際に動かす
        • 思った通りに動かない
        • 展示すると次の改善点が見えてくる
    • 作った感想
      • プロトタイミング大事
      • 物理を感じる
      • 楽しい!!

感想

  • 普段やっていることとは違って、実際にアプリを作っているエンジニアのつらみとつらみの中の面白みを感じ取れたので楽しかった 😊