set setting reset

脂肪と糖にはたらくやつ

de:code 2016 5/24 メモ

会社のお金で de:code 2016 に参加させてもらいました。 とにかく Azure と DevOps 推しでした。 以下、なぐりがきメモです。

Active Directory 最新動向

Azure AD

  • Azure AD
  • 13 億の認証 transaction / day
  • ms が内部でも利用している (yammerも)
  • マルチデバイスサポート

ID 同期

  • Azure AD Connect
    • DirSync サポート廃止
    • 自動アップグレード可能
    • 同期間隔の変更
    • ステージングモード
      • 同期サーバのスタンバイを構築可能
      • stanby はエクスポート不可
      • 昇格可能(failover)
    • AD DS と Azure AD の同期が双方向
      • 365 グループをオンプレに持ってくることもできる
    • マルチフォレスト対応
      • ただし複数の同期サーバは構築不可なので、シングルで構築せざるを得ない
      • 同一ユーザの同期はサポートされない
        • 別々の独立したフォレストに同一ユーザがいるようなケース
    • シングルフォレスト
      • シンプル
      • 基本シングルである方が取り回ししやすい
    • マルチフォレスト
      • ID管理、属性管理に気を使うべき
      • 名寄せしないとアカンケースもあるかもしれない
      • 機能的な制約があることが多い
  • Azure AD Connect Health
    • オンプレの監視
    • ADFS + WAP
  • MIM

    • 複数システム間の ID 同期
    • sharepoint ベースの ID 管理
    • 特権管理
    • 証明書
  • 認証

    • 認証エンドポイント
      • MS アカウントと Azure アカウントを単一の ID として扱うアプリが作れる
  • AAD Join - Windows 10

    • ドメイン参加に Azure AD に参加ボタンがある
    • デバイス情報も Azure AD で一元管理すればいいじゃん
  • MS Passport

  • Office 365 先進認証

  • windows 2016 の ADFS

    • openid connect / oatuth 2.0 対応
    • LDAP を認証ストアとしてサポート

アプリケーション

  • IDaaS
  • AzureAD のほうが認証プロトコルが多い
    • WS2016 から同等になる
  • kerberos は Azure AD は非サポート
    • proxyさせればいいらしい
  • クレーム認証のアプリケーション
    • さまざまな開発言語に対応
  • 独自認証
    • 独自認証はクレーム認証に移行するといいのでは
    • フォーム認証を Azure AD にさせることもできるらしい
    • デバイスの制約あり
  • Azure AD には各サービスのログイン情報を保持できる
    • lastpass みたいな

kerberos 認証

AD application proxy

  • Application proxy connector server にアプリケーションがアクセスして Azure AD にプロキシする
    • アクセスパネル -> azure 上の sharepoint で認証 -> proxy -> オンプレに同期 -> オンプレの sharepoint に SSO

Azure domain service

  • azure ad は GPO がないが、それを azure 上で提供できるようにする
    • ntlm / ldap / kerberos / domain join
    • linux サポート

同期フロー

  • オンプレから Azure AD に同期
  • Azure AD から Azure AD Service に同期
  • Azure AD と Azure AD Service はまったく別物
  • 信頼関係を結べない

制約

  • Domain Admins が使えない
  • read only
  • スキーマ変更NG
  • カスタム GPO NG
  • 規定の GPO しか使えない

AzureAD collaboration

  • 組織間
  • B2B

    • 承認フローを通して外部の ID を自社の AD に組み込むことができる
    • しかも外部の ID 認証は、外部の AD で行う
      • ???
      • Azure AD 上で信頼関係を作成しておくことが前提
      • ただし、テナント間の信頼関係ではなく、テナントと個人の信頼関係
  • 組織外

    • Azure AD B2C
    • ソーシャルアカウントに対応 (FB / Twitter)
      • レアルのファンサイトがこれで実装されている
      • サインインにあたり、Azure AD に登録される

セキュリティ

  • AD Identity protection
    • リスクベースの学習機能を提供
  • 特権管理
    • MIM
      • JIT による特権管理
    • kerberos の拡張
    • 期間限定での認証
  • ATA
    • NW IDS

まとめ


Azure SQL Database

ユースケース

  • クラウドを前提とした SaaS
  • 業務アプリ
  • 細かい監視とかフェイルオーバーとかは IaaS で SQL サーバ作ってちょ
  • 厳密なコントロールとかできましぇん
  • SQL Database と SQL Server のコードベースは同じ
  • 今までは SQL Server => SQL Database というコードの流れだったが、2016 から逆になった
  • .NET / PHP / Java / ODBC
  • ruby / python / Node

概説

  • 学習
    • 稼働履歴からのパフォーマンスチューニングのアドバイスがある
      • index
        • 自動インデックス作成
        • 手動インデックス作成
      • query store
        • 稼働状況を記録
        • SQL Server 2016 と同じ機能
        • 性能が劣化したクエリを特定
        • リソースを消費しているクエリを特定
    • 管理ポータルでのリアルタイム監視
    • Threat Detection
      • 異常なDBアクティビティを検出
        • ポリシー作成
        • alert
        • audit log
  • 拡張
    • basic / standard / premium
    • DTU
      • Database Transaction Unit
      • 相対的なデータベース性能
      • 一般的な一連の操作(OLTP)を実行し、1秒間の性能
      • 100 DTU なら 100TPS ?
      • pay for performance
  • インメモリデータベース
  • elastic database モデル
    • 複数のデータベースをまとめる
    • eDTU という単位がある
    • eDTU の範囲内でオートスケール
    • elastic tool
      • job
      • query
      • transaction
      • 複数の DB を管理できる
  • データの安全性
    • MS Managed
    • Always Encrypt オプションあり
      • クライアント側でデータを暗号化
      • カラム単位
      • 暗号化テキストの検索になるので、完全一致のみサポート
    • 行レベルセキュリティ
    • Azure AD 認証をサポート
    • 動的データマスク
      • 重要なデータをマスクして保護
      • マスクしない特権ユーザを設定可能
  • データの保護
    • レプリカを保持
    • SLA 99.99
  • primary + standby *2
  • Active Geo Replication
    • 最大読み取り可能 DB 4 台

Azure と windows と インフラエンジニアと devops

  • devops に定義はない

インフラエンジニアの役割

  • 手法としては
    • infrastructure as code
    • CI
    • 自動テスト
    • 継続的デリバリ
  • なぜ devops
    • 日々変化するマーケットのニーズに対応する
    • 試行錯誤して改善する
  • リリースのフィードバックが大事
    • フィードバックは ops がするといいね
    • azure なら application insight
  • ops は dev とコミュニケーションして business をうまくまわるようにしましょう
  • ドッグフーディング環境
  • A/B テスト
  • よいフィードバック
  • platform の品質向上
  • マイクロサービスアーキテクチャ
    • 小さく作ってこまめにリリース
    • 機能追加やコード修正の影響範囲を最小化
    • リリース時のテストを少なく & 自動的に
  • フィードバックのセルフサービス化
    • たとえば application insights & power bi
    • まぁ、Excelでもいいじゃん
  • インフラエンジニアは最後の砦
    • システム止まると怒られるのは自分なんだけど・・・

理想と現実

  • no risk = no value
  • high value = hi risk
    • high value を目指さないと意味がない
    • high value = low risk を目指しましょう

ギャップを埋めるテクノロジー

  • Windows Server2016
    • devops を意識しまくり
      • container
        • 迅速なデプロイ
        • 柔軟な変更と rollback
        • リソースの有効活用
          • docker command
          • docker first で powershell を開発している
          • docker command を覚えてちょ
            • container 内でアプリケーションのテスト -> ビルド
            • 動くコンテナをリポジトリにおく
            • 展開する
            • 動かなきゃ戻す
          • windows server container
            • 処理やプロセスは OS に共存する
          • hyper-v container
            • 処理やプロセスはコンテナに独立する
          • windows server container と hyper-v container はいつでも切り替えられる
      • nano server
        • 超軽量インストールオプション
        • 数100MBのサーバOSとして登場予定
      • service fabric
        • アプリケーションクラスタ(ノード)管理
        • 空きリソースでアプリケーションを動かす
        • linux 版も出る
      • 特権アクセス管理
      • 高速化へのアプローチ
  • Azure
    • azure resouce manager
      • infrastructure as code
    • azure stack

devops の具体的な実現手法

  • devopsとは人・プロセス・プロダクトの集合体で継続的にエンドユーザに価値を提供することである
  • devops を導入して 10 deploy / day
  • infrastructure as code で手作業なくして障害をなくそう
  • immutable それは破壊的なインフラ

    • 壊れたら捨てればいいじゃない
  • 本番は学びの場

  • だからこそ適切なフィードバックが必要
  • 継続的な実験と学び

  • infrastructure as code

  • devops は plactice から考えて適用するのがよさそう

  • devops をやるなら dev + ops + えらいひとを集めて話す必要がある
  • devops は agile が前提になっている

    • agile を取り入れるには西洋文化を取り入れる
  • 日本人は生産性が低い

    • 他国とは物量が違う
      • 同じことをやるにも日本じゃ大変
      • やっていることが過剰なのでは?
      • be lazy
        • 無駄なことをしない
      • エッセンシャル思考
        • より少なく、しかしより良く
        • やることを計画的に減らす
      • 世の中のほとんどのことはノイズである
      • ask for help
        • 超気軽に質問する
        • ggrks ??? なにそれおいしいの???
        • 超気軽に断ることも大事
      • チーム / PO / UCD が協力してリードタイムを減らす
  • TDD

    • 失敗するテストを書く
    • コードを動くようにする
    • 重複をなくす(refactor)
  • デプロイを8.5ヶ月から1weekに短縮

    • docker + compose + terraform + serf + azure という例

日本向け devops 導入ステップ

  • value stream mapping
    • デプロイまでの流れを可視化する
    • リードタイムとかをいちいち書き込む
      • 無駄を可視化する
  • 文化とギャップ要素のインストール
  • ハックフェスト
    • プレゼンではなくハッカソンする
    • ペアプロする
  • monitarinng と継続的改善

    • 定期的にリードタイム等の改善状況を共有する
  • MS も Rails と思想は似ている

    • レールに載ってれば快適
    • 魔改造はやめよう

フィードバックの質を上げるために

  • A/B テスト

    • 特定のユーザ
      • どうやるんだろ
    • feature flag
      • ボタン一つでアプリケーションを切り替えられる
  • fault injection

    • 本番で障害を発生させる
    • chaos monkey
    • 障害時に正常に動作するか
  • 10 deploy / day できるようになるために devops しよう

最後にその場でブログをアップして終わり http://simplearchitect.hatenablog.com/entry/2016/05/24/185431