【de:code2017】参加してきました(Day2)
2日目のセッションのまとめです。
ダウンタイムを最小に!-Azureにおける障害/災害に耐えうるアーキテクチャ設計のポイント-
日本マイクロソフト エバンジェリスト 佐藤直生氏によるセッション。
Failure is ALWAYS an option
- 回復性の要件定義で、RTOとRPOを決める
- RTO(目標復旧時間):インシデント後にサービスを復旧しなければならない期間
- RPO(目標復旧時点):データが失われる可能性がある最大期間
従来型アプリ、モダン アプリ
- モダンアプリは、結果整合性を保つことを重視する → 障害のための設計
- クラウドは一時的な障害が多いため、回復性が大事
- 従来型オンプレミスアプリ → アプリを稼働し続けるための設計(MTBF)
- モダンなクラウドアプリ → 障害のための設計(MTTR)
回復性のための設計
- ペアリージョンで広域災害への対策を(東日本⇔西日本)
- 回復性のデザインパターン → クラウドデザインパターン(書籍にまとまっている)
- Traffic Managerを使って、複数のリージョンで動くAppServiceのルーティングを行う
クラウドデザインパターン Azureを例としたクラウドアフリケーション設計の手引き
- 作者: Alex Homer,John Sharp,Larry Brader,Masashi Narumoto,Trent Swanson,日本マイクロソフト,Japan Azure User Group
- 出版社/メーカー: 日経BP社
- 発売日: 2014/06/04
- メディア: 単行本
- この商品を含むブログ (1件) を見る
HA/DRを考慮したアーキテクチャ設計
- HA: High Availability 高可用性
- DR: Disaster Recovery 災害復旧
- サービスによって利用するアーキテクチャパターンが異なる Azure Storage、CosmosDB, SQLDatabaseなど
- 鉄板のリファレンスアーキテクチャ(必修)
まとめ
CTOが語る!イマ注目すべきテクノロジー
日本マイクロソフト榊原CTOによるセッション。
アンビエントコンピューティング
システムの成否はデータ戦略で決まる → データ戦略ドリブンであるべき
- 現代のビジネスはデータ収集ゲーム Data Collection Games
- アンビエントな環境 → 無限のデータ収集
これからの開発は、DevOpsではなくDataDevOps(造語)
Azure*[Blockchain + ML/Cognitive + Fintech + ワークスタイル変革]全部入り
株式会社FIXER千賀氏によるセッション。同社の機械学習のデータ分析から、CognitiveによるAIへの取り組み。さらにBlockchainと連携したオートメーションとCustomer Intelligenceの実現について。
聖剣伝説 Rise of ManaでMachineLearningによるチャーン(離脱)予測
- FIXER Cloud Data Analytics Platform
- プロダクションに組み込める水準の学習ができている
cloud.configの未来系デモ
- AIによるAzureプラットフォームの運用監視
- 障害内容を自動的に学習する
- デモを是非見て欲しい!
Slack + Cognitive(LUIS) + Blockchainで、チャットを利用した事務手続き申請アプリケーション(改ざん不可能!!!)
- slackを利用し、対話形式で購買や事務処理手続きをオートメーション化
- また、Blockchainの活用により申請者、承認者などの改ざんができないため、コンプライアンス対応!
- Baas(Blockchain as a Service)を利用することで開発も容易に
- これも、是非デモ動画を見てほしい、凄く便利そう!!
米国マイクロソフト本社で体験したノウハウを伝授!マイクロサービス実行基盤Azure Service Fabricの勘所
日本マイクロソフト エバンジェリスト 井上大輔氏によるセッション。
Service FabricはAzureの多くのサービスの基盤となっている
- アメリカではかなり注目され、導入実績もある
MSA(MicroService Architecture)モデルの理解と実装 → それ、Service Fabricが全部やるよ
オンラインショッピングのマイクロサービス化
- サービス分割の方針 → It’s not a science, art
まとめ
日経BP書籍ブースで買いました!
プログラミングAzure Service Fabric (マイクロソフト公式解説書)
- 作者: Haishi Bai,佐藤直生監訳,クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2017/02/25
- メディア: 単行本
- この商品を含むブログを見る
システムの信頼性を上げるための新しい考え方SRE(Site Reliability Engineering)in Azure, on Azure
日本マイクロソフト クラウドソリューションアーキテクト 真壁 徹氏によるセッション。 Googleの提唱する「Site Recovery Engineering」についての紹介、並びにAzureを利用した開発におけるSREのあり方。
参考:Site Reliability Engineering (SRE)チームとは - yoshidashingo
重要な考え方:Error Budget(どれだけの障害・停止が許容できるか?)
- オンプレとクラウドの設計思想の違い
- オンプレは Design to avoid failure
- クラウドは Design to Failure
- SREのミッションは、「Time to Mitigateを短縮する」こと → サービスがとりあえず使えるようになるまでの時間
重要なプロセス:Service Roast
- Service Roastとは、SREチームとプロダクトチームとのミーティング
- マネージャーを呼ばない
- 成果物は相互理解
先人の知恵と実績を活かす(鉄板構成、リファレンスアーキテクチャ)
- 必要に応じて崩す
- PowerShellからARMテンプレートを作成するスクリプトを実行 → 瞬時にリファレンスアーキテクチャが構築される
- フェールオーバーのデモ:WebAppを停止してSQLDatabaseをフェールオーバーさせると、別リーションのWebAppとSQL Databaseが立ち上がる!
Ask the Speaker
社内でもSLA合意はやったほうがよいか
クラウドの特性を理解してもらうためにも、実施したほうがよい。その上で、どの程度のSLAが必要になるのかをディスカッションすべき。
インフラ担当者から、可用性を担保したアーキテクチャ(テンプレート)を利用者に展開する手法でオススメなのは
アーキテクチャ自体を資料として提供しても、そこに人の手が入る余地があると良くない。Demoで行ったようなPowerShellスクリプトを利用したテンプレート展開が望ましい。
所感
- エモくてすごく良いセッションだった(Service Roastのあり方、悩みは人間関係、などなど…)
- もっと欲しい
獲れたて OSS x DevOps!自動化三昧を満喫セヨ
- 動画メイン
- 自動化というより、Kubernetesに興味のある方向け
- VSTSには触れません
株式会社アシックス様におけるAzureAD導入プロジェクトの実際
伊藤忠テクノソリューションズ株式会社 富士榮尚寛氏によるセッション。全セッション中で最も参考になった。
ブログにもしょっちゅうお世話になっている(本当にお世話になっております) idmlab.eidentity.jp
導入目的:クラウドアプリを安全に使いたい(SSO)
- Google Apps(G Suite)
- Salesforce
- ServiceNow
- Concur
課題
- ID/パスワード漏洩
- パスワード認証の限界、さらに本人が気が付きにくい
機能要件
- 認証 Authentication
- 認可 Authorization
- 管理 Administration
- 強固な認証
非機能要件
機能要件だけでなく、非機能要件もリスト化して検討を行う
- セキュリティ要件 CIA
- 機密性 Confidentiality
- 完全性 Integrity
- 可用性 Availability ← 一番重要!!!
他社IDaasなどと比較した際の、AzureAD選定の理由
- SMSが月額従量課金
- 既存パスワードが利用可能(Azure AD Connect)
- 利用したいクラウドアプリの接続検証が完了している(拡張性高)
実案件におけるAAD
AADと一緒に利用しているAzure関連リソース一覧と、その利用方法。
MFA展開用Webアプリケーション
- 切り替えをスムーズに行うための準備サイト
- 移行期間中に、このWebサイトでデバイスとIDを登録しておいてもらう
Azure AD Connect
- 各リージョンのローカルADから、Azure AD Connectを利用してID同期を行う
Conditional Access(条件付きアクセス)
- 認証用のデバイスを自宅に忘れることがある
- 除外グループを作成し、一時的にユーザーをそのグループに追加して認証をバイパス
- グループのユーザーは自動で(Azure Automation)強制クリアされる
まとめ
- AzureAD導入には、クラウドを前提とした運用体制がキモ
- また、機能をフルに活用するための学習は必須
Ask the Speaker
AzureADのライセンス(Premium, EMSなど)は複数利用する場合、ディレクトリを分けているのか?
一つのディレクトリに複数のライセンスが登録可能。そして、ユーザーごとにライセンスを適応して運用している。
EMSでデバイス認証を一部している、その用途は?
MdMより、MaMの用途で利用している(アプリケーションをデバイスに強制インストールさせたい場合)。
MFAを利用する場合、該当AzureADのカスタムドメインに対応したメールサーバを作成する必要があるか?
MFAの初回認証時にメールアドレスを登録する必要があるため、別ドメインでメールサーバーがあるならばそちらのアドレスを登録するのもよい。
その他
EMSを利用したデバイス認証は、デバイスの管理コストが高くなる。できることならやらないし、やったとしても一部だけの適応に留める。
ありがとうございましたm( )m
Day2まとめ
自分の興味というより、仕事で必要な知識を得るためにセッションを選んでしまった。得るものもたくさんあったが、もう少しバランスを考えてスケジュールを組むべきでした(XamarinやHoloLensに興味はあるものの、仕事ですぐに使うことは…などと考えてしまった)。
クラウドのセキュリティとID管理が、今一番熱い!(゚∀゚)
それにしても、一つひとつセッションが濃かった…(´・ω・`)
Channel9で動画が上がったら、もう一度見直す。