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 サポート廃止
- 自動アップグレード可能
- local SQL Server が稼働
- powershell で管理できる
- 同期間隔の変更
- 3h -> 30 min
- powershell で管理
- ステージングモード
- 同期サーバのスタンバイを構築可能
- 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 先進認証
- office client の AD 認証ライブラリ
windows 2016 の ADFS
アプリケーション
- IDaaS
- AzureAD のほうが認証プロトコルが多い
- WS2016 から同等になる
- kerberos は Azure AD は非サポート
- proxyさせればいいらしい
- クレーム認証のアプリケーション
- さまざまな開発言語に対応
- 独自認証
- 独自認証はクレーム認証に移行するといいのでは
- フォーム認証を Azure AD にさせることもできるらしい
- デバイスの制約あり
- Azure AD には各サービスのログイン情報を保持できる
- lastpass みたいな
kerberos 認証
- windows 統合認証
- ?
AD application proxy
- Application proxy connector server にアプリケーションがアクセスして Azure AD にプロキシする
- アクセスパネル -> azure 上の sharepoint で認証 -> proxy -> オンプレに同期 -> オンプレの sharepoint に SSO
Azure domain service
同期フロー
- オンプレから Azure AD に同期
- Azure AD から Azure AD Service に同期
- Azure AD と Azure AD Service はまったく別物
- 信頼関係を結べない
制約
AzureAD collaboration
- 組織間
-
- 承認フローを通して外部の ID を自社の AD に組み込むことができる
- しかも外部の ID 認証は、外部の AD で行う
- ???
- Azure AD 上で信頼関係を作成しておくことが前提
- ただし、テナント間の信頼関係ではなく、テナントと個人の信頼関係
組織外
- Azure AD B2C
- ソーシャルアカウントに対応 (FB / Twitter)
- レアルのファンサイトがこれで実装されている
- サインインにあたり、Azure AD に登録される
セキュリティ
まとめ
- オンプレ + Azure AD = Active Directory
Azure SQL Database
- SQL Server と SQL Database の違い
- PaaS
ユースケース
- クラウドを前提とした 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 と同じ機能
- 性能が劣化したクエリを特定
- リソースを消費しているクエリを特定
- index
- 管理ポータルでのリアルタイム監視
- Threat Detection
- 異常なDBアクティビティを検出
- ポリシー作成
- alert
- audit log
- 異常なDBアクティビティを検出
- 稼働履歴からのパフォーマンスチューニングのアドバイスがある
- 拡張
- basic / standard / premium
- DTU
- Database Transaction Unit
- 相対的なデータベース性能
- 一般的な一連の操作(OLTP)を実行し、1秒間の性能
- 100 DTU なら 100TPS ？
- pay for performance
- インメモリデータベース
- elastic database モデル
- データの安全性
- MS Managed
- Always Encrypt オプションあり
- クライアント側でデータを暗号化
- カラム単位
- 暗号化テキストの検索になるので、完全一致のみサポート
- 行レベルセキュリティ
- Azure AD 認証をサポート
- 動的データマスク
- 重要なデータをマスクして保護
- マスクしない特権ユーザを設定可能
- データの保護
- レプリカを保持
- SLA 99.99
- primary + standby *2
- 同期レプリケーション
- 常に 3 台構成
- 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
- リソースの有効活用
- nano server
- 超軽量インストールオプション
- 数100MBのサーバOSとして登場予定
- service fabric
- 特権アクセス管理
- 高速化へのアプローチ
- CPU ボトルネックの世界が来てる
- container
- devops を意識しまくり
- Azure
- azure resouce manager
- infrastructure as code
- azure stack
- azure resouce manager
devops の具体的な実現手法
- devopsとは人・プロセス・プロダクトの集合体で継続的にエンドユーザに価値を提供することである
- devops を導入して 10 deploy / day
- infrastructure as code で手作業なくして障害をなくそう
immutable それは破壊的なインフラ
- 壊れたら捨てればいいじゃない
本番は学びの場
- だからこそ適切なフィードバックが必要
継続的な実験と学び
infrastructure as code
- visual studio から docker コンテナデプロイ
- visual studio から仮想マシン起動
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
