行ってきたので内容をメモった。Azureは未経験。
CD12 Kubernetes関連
- Session: CD12 / マネージド Kubernetes ガチ本番運用 in ZOZOTOWN
- Date: 2019/05/29
- Place: 港区芝公園ザ・プリンス パークタワー東京
- Official URL
Presentation
- Kubernetes運用の目的
- システムの安定稼働を目指す
- サービスの成長、突発的なアクセス負荷に耐えられるインフラ
- コンテナ化、オートスケール、オートヒーリングによる運用負荷の低減
- マイクロサービス、マルチクラウド化を視野に入れた設計
- システムの安定稼働を目指す
- Kubernetesを運用にしてみて
- 運用が楽になる反面、通常運用まで持っていくのに相当な知識が必要
- Kubernetesのversion upサイクルが早く、常に追いついていく必要がある
- Microsoft unified supportが手厚い
- 問い合わせ制限無し
- MSの技術者と問題解決に向き合える
- オンプレの問題もMSに相談可能
- コスト面
- Azureのmaster nodeリソース分の料金が減る
- 運用負荷も軽減
- カスタマイズ幅が小さくなるが、必要性はあまり無いと感じる
AKSの特性
- Azure Active Directory
- 各種リソース操作権限はAzure ADにより管理、AKSの操作も同様
- type: LoadBalancer (Azure Load Balancer)
Kubernetesでの障害例
- HTTP status 400,500,502エラー発生も、原因追求が困難
- どのレイヤーで発生している障害なのか?
- HTTP connection, TCP/IP connection, DB connection
- どのレイヤーで発生している障害なのか?
- 突然podがapply出来なくなる事象
- Service Principalの期限切れでクラウドリソースの操作不可となったことが原因
- nodeやpodが落ちる場合がある
- Azure VMのバグによるnode停止
Summary
Kubernetesを運用する上でのテクニック
- サービス継続可能なpod数を維持
- maxSurge, maxUnavailable
- deploymentを用いたrolling update時
- PodDisruptionBudget
- nodeからのdrain時
- maxSurge, maxUnavailable
- アクセスの強制切断を防ぐ為、Graceful Shutdownを設定
- lifecycle.preStop
- podのtermination時に実行される処理
- podのrestart時に必要となる
- serviceの更新とpodのterminationは非同期であり適切な設定が必要
- lifecycle.preStop
- health check
- Liveness Prove, Readiness Probeの設定
- pod起動時間を考慮してProbeを開始
- DBのtimeoutを考慮
- Liveness Prove, Readiness Probeの設定
- podのpending時はnodeのauto scalingが有効
- cpu, memoryリソースに余裕が無い場合、podがpending状態で起動しない場合がある
Digression
AWS ECSの場合、コンテナが確保するリソースに対しホストのリソースが足りない場合は、Taskの実行→コンテナが起動するもリソースが足りずに落ちるというのを無限に繰り返すが、Kubernetesの場合はpodがpending statusになるとのことでその方が遥かに分かりやすい。Azure Monitorによってコンテナ毎にリソース状況、各コンテナのログを確認出来るようで、pendingになっている要因もそこから読み取れそう。
※ 尚、AWS ECSのTask Rolling updateの流れは以下の通りである。
Task Definition(A) deploy → Task Definition(A) start → Task Definition(B) deploy → Task Definition(A,B)が混在 → Task Definition(A)停止 → Task Definition(B)のみ起動
検証から半年で、少人数のチーム(5人?)で運用に乗せるまでは、相当な検証と失敗を相当反復したに違い無い。お疲れ様でした。
CD01 Windows Containers
- Session: CD01 / Windows ContainersとAzureによる、既存.NETアプリケーションのモダナイゼーション
- Date: 2019/05/29
- Place: 港区芝公園ザ・プリンス パークタワー東京
- Contents: オンプレミスで稼働する.NETアプリのWindows Container化やWindows Server2019でのWindows Containersの機能差分。
- Official URL
Agenda
- Windows Containersの動向
- WindowsのDocker Engineとimageの種類
- Windows Server Core imageと、既存.NET Frameworkアプリケーションのモダナイズ
- Visual Studioでコンテナ化
- Azureへの展開
Presentation
当該セッションにて重要だと僕が思ったところを抽出した。Azure自体触ったことが無いため、誤った独自の解釈を含んでいる場合は指摘いただけると助かります。
Windows Containers Platformの進化
Windows Versions
LTSC (LONG-TERM SerVICING CHANNEL) だと2-3年単位だが、SAC (SEMI-ANNUAL-CHANNEL) 単位だと6ヶ月単位でのversionリリースの為、細かいversion upや最新versionに追従したい場合はSACを検討すると良さそう。
Docker image
- Windows Hyper-V分離コンテナーの特徴
- プロセス分離コンテナーと同じAPI、Imageを使用。
- 各コンテナ専用のkernel copyが存在。
- Windows プロセス分離コンテナーの特徴
- Windows ContainersでのHW support。
docker run --isolation=process --device="class/{interface class GUID}" mcr.microsoft.com/windows/servercore:1809
- DirectX GPU Acceleration (GPU対応)
docker run --isolation=process --device class/5B45201D-F2F2-4F3B-85BB-30FF1F953599 <mcr.microsoft.com/windows:1809 以上>
- Windows ContainersでのHW support。
docker run -it --isolation=hyperv mcr.microsoft.com/windows/nanoserver:1809 cmd
Windows Server Coreイメージと既存.NET Frameworkアプリケーションのモダナイズ
Windows Containersの展開先としては以下がある。
- Azure Container Instances (ACI)
- Azure Virtual Machine
- Azure App Service
- Windows Container対応はpreview
- Service Fabric (Mesh or Cluster)
- microserviceのpackaging、deploy、運用を簡略化する為のScalableな分散システムplatform。
- Service Fabric Meshは現在preview。
- 一般的なworkload
- コンテナベースのmicroservice。
- プレーンなプロセスをベースにしたmicroservice。
- statefulなサービス。
- Azure Kubernetes Service
- Cluster(multiple hosts)上におけるコンテナの自動デプロイ、自動Scaling、運用の為のOSS platform。
- Windows Container対応は現在preview。
- 一般的なworkload
- コンテナベースのmicroservice。
Summary
Windows Server2016からWindows Containerは利用出来るようになっているものの、2019辺りからKubernetesとの連携やアプリとの互換性が強化されてきている為、アーキテクチャが許されるのであれば最新版のOSを利用するのが良いだろう。
Linux Containerと比較しWindows Containerはまだ多くの制限、制約がありそうな雰囲気だが、Hyper-V分離Container等で構成すれば解消するという理解。
Nano Serverを利用する場合は.NETアプリケーションを実行出来ず、.NET Coreが必要である。サイズもNano Server以外は1.5~3.5GBと巨大。Docker imageのdownload, deployに時間が掛かるだろう。さらにホストはコンテナと同じWindows Versionが実行されなければならず、ホストがVersion1803であるならばコンテナもあわせ1803が実行されている必要があるが、これはHyper-V分離Containerとして実行することで解消出来そう。ただ、構成が複雑になり学習コストは高そうな雰囲気。
現時点で.NET Coreを利用してクロスプラットフォーム化されているアプリケーションであるのならば、Windows Containerを利用する明確な理由が無ければ、Linux Containerを利用する手段を検討しても良いと思う。まだContainer OrchestrationであるKubernetes、Service FabricはWindows Containerに関してプレビュー段階であり、GAして数年の内にやっとProduction環境でも利用する事例が出てくるのではないだろうか。
SE01 Azure AD Log/Azure Monitor
- Session: SE01 / Azure Active Directory の ログ の "みかた" 長期保存・外部 SIEM 連携・分析手法
- Date: 2019/05/29
- Place: 港区芝公園ザ・プリンス パークタワー東京
- Contents: Azure Active Directoryの監査/セキュリティログ、外部ログ連携機能、Azure Storage、Azure Event Hubs、Azure Monitorの紹介、見方、使い分け
- Official URL
Agenda
- Azure ADが出力するログの種類
- そのログが何の役に立つのか
- 消えていくログを正しく保持・管理する方法
- 現時点でのログの"みかた"の整理
Presentation
当該セッションにて重要だと僕が思ったところを抽出した。Azure自体触ったことが無いため、誤った独自の解釈を含んでいる場合は指摘いただけると助かります。
Azure AD
- Sign in log
- ログへアクセスできる権限は、Global Administrator, Security Administrator, Security Reader, Reports Reader の4role。
- 閲覧範囲は同じ。
- サインインログでアプリケーションの利用率や行動パターン、サインイン失敗ログ、セキュリティインシデントのログが閲覧可能。
- Refresh tokenの確認は不可。ADFS(Active Directory Federation Services)、外部IdP(Identity Provider)経由でのログイン失敗はログに記録されない。
- ログへアクセスできる権限は、Global Administrator, Security Administrator, Security Reader, Reports Reader の4role。
- 監査ログ
- 記録されるのは、リソースの変更、user/applicationのprovisioning、パスワードリセット、PIM(Product Information Management)の評価、使用条件の許諾、Azure B2Bの招待、承諾
- セキュリティログ
- アクティビティログからセキュリティに関するインサイトを提供。
- ※ 全アクションが記録される訳ではない。
- リスクレベルを分類された攻撃が行われた可能性のあるアカウントがリストアップされる。
- セキュリティリスクの具体的な検知内容を提供。
- 資格情報漏洩
- 以下のサインイン情報
- 匿名IP Address、感染デバイス、不審なアクティビティのあるIP Address、未知の場所
- アクティビティログからセキュリティに関するインサイトを提供。
ログの保持・管理方法
Azure Blob
- (ログに関しては) archive向け、長期保存用
Azure Events Hubs
- 膨大なtelemetry, event情報の受信hub。
- 外部SIEM(Security Information and Event Management)と連携が可能。
- Azure Monitor Logs (旧Log Analytics)
- ログ収集・分析基盤
- 高速な検索基盤
- 改竄不可、Roleベースのアクセス制御
- ※ 但しvisualizeが面倒という風の噂
Summary
- Azure ADのログは調査・監査が目的のActivity LogとInsightを提供するSecurity Logの2種類。
- ログの長期保存はBlob Storage、外部SIEM連携はEvent Hubs、調査・監査・分析はAzure Monitorを利用する。
Digression
- 用途によってログの転送先は分けつつ、アクセス制御を行うことは比較的簡単に行えそうな雰囲気だった。
- AWSだと長期保存用としてAmazon Gracierを利用するが、抽出するのが手間な為、Azure Blob StorageではオブジェクトへHTTP/HTTPS経由でダイレクトにアクセス可能なのは良いと思った。
- de:code2019で
Azure Monitor(LogAnalytics)とは (SE01)の図を3度は見た気がする。それほどアピール要素が詰まっているということか。
CD13 Azure Monitor
- Session: CD13 / クラウド ネイティブ / ハイブリッド アプリケーションの監視 ~ DevOps モニタリング アーキテクチャ ~
- Date: 2019/05/30
- Place: 港区芝公園ザ・プリンス パークタワー東京
- Contents: Azure Monitor、Azure Monitor Logsのdata source
- Official URL
Agenda
- Azure Monitorとは何か
- Azure Monitor Logsのデータソース
Presentation
当該セッションにて重要だと僕が思ったところを抽出した。Azure自体触ったことが無いため、誤った独自の解釈を含んでいる場合は指摘いただけると助かります。
Azure Monitorによるクラウド-ネイティブ/ハイブリッドアプリケーションの監視
Azure Monitorでアプリケーション、インフラストラクチャ、ネットワークのログ収集、分析を一括管理可能。
※ 複数の異なる監視ツールを利用する必要がない。
- 以下のログを収集
- APM (Application Performance Management) によるWeb Appの可用性、Performance、使用状況、エラーログの監視(Application Insights)
- Syslog、Event Log、Performance Counter Log
- IIS等MWのログ
- Azure resourceの操作ログ
- Azure subscriptionの操作、管理ログ
- Azure tenant level (Azure Active Directory)の操作ログ
- AKS (Azure Kubernetes Service) のコンテナリソース、ログ監視
- 仮想マシンとAKSのインフラストラクチャレベルの問題を関連付け
- スマートアラート機能によるアラート通知自動化
- Azure Monitor Logsでトラブルシューティング
Azure Subscription ログ
- Subscription (※1.) 内のAzure serviceの正常性に関する情報を提供
- Azure Resourceに対し行われた構成変更
※1. Subscriptionについてはこちらが分かりやすかった為、引用させていただきます。
Azureが出力するログ
- Activity Logs
- リソースに対し外部から誰が何を行ったか記録する。
- Log Analytics workspaceが同一subscriptionにある場合、workspaceと紐付けるだけでActivity Logがworkspaceに転送される。
- 90日間は基盤側に保存。
- 別workspaceの場合、Event Hub, Logic Appを利用してログを格納させる。
- Diagnostic Logs
- 各リソースが出力する診断ログ。
- 多くのserviceの診断設定でLog Analytics workspaceを指定することで転送可能。
- metricsは93日間Monitorのmetric storeに自動保存されるが、診断ログは自分で設定が必要。
Application Insights
- App Mapによるサーバー・クライアントの関連性や依存関係を視覚化。
- 分散されたE2Eトランズアクションのトラック。
- Snapshot DebuggingとProfiling機能でコードレベルまでドリルダウン。
- エンドユーザーの行動把握。
Custom Sources
- 他社クラウド、オンプレ経由でも、以下のことが可能。
- REST clientからCustom Metrics APIを介してAzure Monitor Metricsへデータ保存。
- REST clientからCustom Data Collector APIを介しAzure Monitor Logsへデータ保存。
その他データソース
- Azure Security Center
- 収集したセキュリティ関連のデータをLog Analytics workspaceへ保存しAzure Monitorで収集された他データと一緒に分析可能。
- Azure Sentinel
- 様々なdata sourceから収集したデータを (同上)。
Digression
Azure Seriviceの各種ログ関連はデフォルトでの保持期間が比較的短い為、トラブルシューティング的な用いられ方で利用し、アーカイブ・分析を目的とした利用は、subscriptionとworkspaceを意識して転送設定を都度行う (Log Analytics workspaceへログを集約する) 必要性があると感じた。
基調講演では、スクリーン上部に精度の高い自動翻訳が流れていた。
話の区切りで終始差し込まれるショートムービーでは、企業ミッションである 地球上のすべての人、すべての組織に関わる人たちが、より多くのことを達成する力になること を体現するかのような世界観を表しているように思えた。
AIりんなの歌声は人間そっくりで、歌自体鳥肌立つほどに上手かった。
お昼に出たお弁当はなだ万だった。1日目はThe 懐石料理という感じで肉が少なく物足りなかったが、2日目の方は唐揚げもありデブにはとても嬉しかった。
以上。
