マイクロソフト主催テックカンファレンス「de:code 2019」へ行ってみた

Azure Kubernetes UI / UX DevOps Event
このエントリーをはてなブックマークに追加 follow us in feedly

こんにちは。オプティムのプラットフォーム事業本部 SREチームの津田です。 日本マイクロソフト主催の開発者向けテクニカルカンファレンス「de:code 2019」に参加してきました。
同じく「de:code 2019」に参加した2名にも、記事作成を手伝ってもらい、合計3名がそれぞれ1セッションを担当して作成しています。 プラットフォームテクノロジー戦略室の宮崎が、「モバイルアプリ：SPA？ネイティヴ？UX/UIの違いと技術選択のポイント」、SREチームの中岡が、「DevSecOps時代のログマネジメントとセキュリティ」のセッションを担当しています。

イベント概要

イベント: de:code 2019
日時: 2019年 5月 29日 ~ 30日
場所: ザ・プリンスパークタワー東京

f:id:optim-tech:20190612191832p:plain

全体を通しての感想

HoloLens2 や新しい Terminal の発表など魅力的な内容の詰まったイベントでした。
展示では、様々な企業がAI、IoT、働き方改革をテーマに出展していました。Microsoft主催なだけあり、Office365の活用や運用サポートが目立っているように感じました。弊社もAI/IoTプラットフォームを提供している立場なので、「今どんなサービスが注目されているのか？」「そのサービスは使いやすいのか？」という視点で眺めていました。
また、Kubernetesや分散トレーシングなどクラウドネイティブな技術について取り上げているセッションが多くあり、これらの技術を使用しているSREチームとしては、もっとアウトプットしていかなければならないなと感じました。

セッション

モバイルアプリ：SPA？ネイティヴ？UX/UIの違いと技術選択のポイント

セッション内容

言葉の定義
  • SPA (Single Page Application)
    • ここでは、HTML5及びJS/TSベースのものを指し、PWAは対象外とする
  • ガワ Native
    • アプリの UI の View に WebView を利用し、UI をサーバ配信するアプリを指す
  • Native
    • iOS API、Android API で UI を構成するアプリを指す
技術選択のポイント

残念だが、どんなシナリオにでもあてはまるような銀の矢(銀の弾丸のこと?)は存在しない。
しかし、技術への理解を深め、よりベターな選択をすることは可能である。
そのポイントを紹介する。

ホーム画面のアイコンの違い
  • iOS

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-13-638.jpg

(出典：https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

  • Android

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-14-638.jpg?cb=1559104318

(出典：https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

SPA、ガワ Native、Nativeそれぞれ見た目が異なる。

UIの違い

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-15-638.jpg?cb=1559104318

(出典: https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

上の画像はデフォルトのデザインの UI 部品を並べたものである。
テキストボックスなどの部品が Native とそれ以外と比較すると、Native の方がよりフラットなデザインになっていることがわかる。
また、ここではご覧にいれることはできないが、「動きのある UI」の場合はもっと大きな差がある。 (e.g.フリックやドラッグ＆ドロップで操作するもの等)

アプリで大切なことは「ユーザーに何を届けたいか」
  • ユーザーが気にすること

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-21-638.jpg?cb=1559104318

(出典：https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

  • ユーザーにリーチするために必要なこと

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-22-638.jpg?cb=1559104318

(出典：https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

アイコンが「かっこいい」というのも大事な要素である。

技術・プラットフォームの特徴
  • 配信プラットフォームと配信・決済方法

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-25-638.jpg?cb=1559104318

(出典：https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

  • ユーザーは独自決済よりもストア決済のほうがより安心感がある
    • 課金はストアで行われやすい傾向にある
  • アプリのアップデートは SPA など Web に依存する部分は開発側がアップデートすればそれで完了だが、Native になってくるとユーザーがアップデートしなければならない
    • アプリが更新されユーザーにアップデートを促した際、ユーザーの通信量制限がかかっていた場合等は大変である
    • 配信はSPAだと開発側の意図したタイミングでリリースできるが、ストアを経由する Native などは審査待ちなどが生じる
  • 配信プラットフォームと機能

https://image.slidesharecdn.com/decode19slideshare-190529043040/95/decode2019-mw52-spauxui-27-638.jpg?cb=1559104318

(出典：https://www.slideshare.net/TomohiroSuzuki4/decode2019-mw52-spauxui-148064384)

  • 機能は Native の方が高い機能を提供でき、ガワ Native、SPA になってくると必要最低限の機能提供となる
  • よくあるカメラ、プッシュ等といった機能は Native、ガワ Native でないと使えない機能

感想

最終的にはユーザーに何を届けたいかということを念頭に選択をしていくのでしょうね。その中で何がベターなのかというのを前述の内容を材料として考え、自分たちのもつリソース（時間、人手、スキル、etc...）から最適解を導き出す。言うは易しのように聞こえますが、技術やプラットフォームの特徴を理解する前と後では少し見えている世界が違ってくると思います。 OPTiMのアプリ開発でもここは議論になる部分であり、SPAやガワ Native などのWeb ではファイル操作や、毎回レイアウト情報が通信路に乗るため通信量が膨大になりやすいこと、ブラウザアプリでは1回のリクエストでやり取りできるデータ量に制限が設けられている等といった観点に弱いため、ファイル操作するアプリや大量データ通信をする場合などは Native を選択することが多いです。今回の講義で学んだ観点を理解し、要素のメリデメ、プライオリティを一つ一つ検証して最適解を導いていきたいですね。

DevSecOps時代のログマネジメントとセキュリティ

セッション内容

ログ設計のロジック
  • ログの利用スキームから設計方針を決める
  • 開発ログ
  • 運用ログ

  • 監査ログ

  • 全てのログには担当者ごとのアクセス制御と作業記録が必要

開発
  • 作業
    • 想定外の処理について修正する
  • 判断
    • 想定した処理が行われているかを判断する
  • レポート
    • プログラムの処理やデータの推移などを詳細に表示
  • ログ管理
    • 処理状況を詳細に記録する
運用
  • 作業
    • 想定した範囲内のパフォーマンスとなるように修正
  • 判断
    • ITパフォーマンスのKPIを設定し、遵守状況を判断
  • レポート
    • アラートなどを設定し、いつでも適切な判断ができるようにする
  • ログ管理
    • ユーザの作業データなどを活用した相関的な判断
監査
  • 作業
    • 法律や標準規格に応じた監査項目について報告書を作る
  • 判断
    • 監査人がITの設計や処理が適切であることを判断する
  • レポート
    • 監査証跡として活用できる記録を客観的に保管する
  • ログ管理
    • 監査証跡として客観的に利用できるように記録する
Azureのログ活用サービス
  • それぞれのスキームにおいて、要件が異なる
  • ダッシュボード、セルフサービスインターフェース、リモートジャーナリングなどのツールを活用する
DevSecOpsとレジリエンス
  • ログを見て判断する部分を「自動化」する
  • 膨大なログを持っていると、処理に時間がかかる
  • インテリジェンスとAIの活用
  • ログ設計は作業からの引き算で作る

感想

セッションの中で印象的だったのは、「開発ログにはユーザの重要な情報が含まれている場合も多い。それをそのまま運用者に渡してしまうと問題となるため、必要な項目のみに絞って渡す必要がある。」という事でした。確かに氏名や処理結果のテキストなど、個人情報に繋がるログが記録されるケースもあります。

「そのログは誰が見るのか？」 「必要な情報は何か？」 という観点で、設計すること、必要に応じて暗号化などの処理をする事、そしてMicrosoftのセッションらしく、「Azureのサービスでログの管理もできますよ」という下りで終わっていました。

「自動化」や「AI」は、セッションだけでなくカンファレンス全体でよく見かけるトレンドキーワードとなっております。

OPTiMでも「AI Camera」による画像解析サービスを展開しています。その基盤として「Cloud IoT OS」というプラットフォームサービス（PaaS）を提供しています。

弊社のサービスでも、やはりログの管理と運用・監視には悩まされています。 本セッションは、身近な「ログ」という題材を見直すきっかけとなりました。

マネージド Kubernetes ガチ本番運用 in ZOZOTOWN

www.youtube.com

セッション内容

背景

ZOZOTOWNは、今までオンプレ運用がメインだったが、以下のような問題点があったため、クラウド移行/コンテナ化/Kubernetesの検討を始めた。

  • オンプレのためサーバ追加が柔軟ではない
  • サーバ構築や運用での手動設定が多く、運用負荷が高い
目的

Kubernetes運用の目的としては以下がある。

  • システムの安定運用
  • 運用負荷の軽減
  • マイクロサービス化、マルチクラウド化を視野に入れた設計
    • Why マルチクラウド
      • 可用性の向上
      • AKSはSLAが無いこともあり、1つのクラウドサービスに障害があった時でも、システムを常に動作させる状態にしたいため
なぜManagedなKubernetesを使用したか

  • メリット

    • コスト面
      • Azure上リソースが削減できる
    • 運用面
      • セットアップが楽
      • MasterNodeを管理しなくていい
      • サポートへの問い合わせが可能

  • デメリット

    • カスタマイズ幅が少なくなってしまう
      • そもそもカスタマイズするのか？
      • 通常運用で安定稼働させるまでが大変なので、Managedで良い
AKSの特性
  • Azure Active Directory
    • 各種リソースの操作権限はAzure Active Directory によって管理される
    • Azure Resource であるため当然と言えば当然
  • Kubernetes Service
    • Kubernetes Service Type:LoadBalancer を作成した場合、実体としては、Azure LBになる
AKS特有の障害
  • 事象: 突然PodがApply不可になった
  • 原因: ServicePrincipalの期限切れでクラウドリソースの操作ができなくなったこと
本番運用
  • 本番運用前の検証、実測が大事
    • Managedだから任せられるわけでは無い
  • Kubernetesの知識は必要
    • 動作を理解しなければ検証できない
  • 検証・実測できる環境を作る
    • クラスタを使い捨てる
      • 本番稼働中の環境を変更しない
      • 人間なのでどの環境を変更したか忘れてしまう
      • LoadBalancerでクラスタを切り替えるなど
想定外の事象
  • NodeやPodが落ちることがある
    • KubernetesはPodが落ちた時に自動で再起動を行うなど、ある程度落ちることを許容した作りになっている
    • 再起動時にエラーが起きないように設計/チューニングしなければならない
      • サービスが継続できるPod数を常に確保する
        • maxSurge、maxUnavailable を設定する
        • PodDisruptionBudget を設定する
      • アクセスの強制切断が発生しないように、Graceful Shutdown を設定する
      • ヘルスチェック
        • Liveness Probe、Readiness Probe の設定
        • データベースのタイムアウト値を考慮するなど
      • リソース制限
        • resources.requests、resources.limitを設定する
      • Pendingが発生するならNodeのオートスケールが必要
総括
  • 覚えることが多く、躓いた部分もあったが、安定運用している
  • クラウド化により、リソース不足の心配がなくなった
  • コンテナ化したことでマイクロサービス化の足がかりになった
  • Managed Kubernetes にすることでコストを削減しつつ、運用不可も軽減できた

感想

現在、弊社のCloud IoT OSでも一部の環境でAKSを使用しているという経緯もあり、他社のKubernetesの実用例を知りたく、セッションに参加しました。 AKSの特性や、特有の障害の話を聞いて、弊社でも同じような部分で苦労しているため、共感する部分が多くありました。 また、maxSurgeなどの設定を行うことや、Graceful Shutdown、ヘルスチェックやリソース制限などのPodが再起動してもエラーにならないような設定は、Kubernetesを運用するにあたって参考になりました。これから、社内の活動でも一例として活用していきたいです。 また、弊社でもKubernetesを運用しているので、本セッションの様にアウトプットしていきたいなと感じたセッションでもありました。

おわりに

今回の「de:code 2019」のような外部イベントは平日に行われる事が多いため、参加するための調整が難しい（有給休暇を取得して個人参加する等）ですが、OPTiMでは業務の一環として参加し、社内への情報共有を推進しています。
OPTiM では一緒に働く仲間を募集しています。 興味を持もたれた方はぜひお問い合わせをお願います！

www.optim.co.jp

また、夏季インターンシップも行いますので、 興味を持もたれた学生の方はぜひお問い合わせをお願います！

www.optim.co.jp