Hejdaの見る夢

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

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さ差0ビス管理フォーカス
    • 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