メインフレーム、無停止サーバ、クラウドにおける信頼性
「メインフレームの異常処理」という記事が話題になってましたがとても面白かったです。 qiita.com
せっかくなので自分が知ってる範囲で各システムの信頼性における考え方を書いてみました。特にシステムが死んでも仕掛かり中のプロセスが正常完了する事を「無停止システム」としてフォーカスしています。 詳しいわけじゃないからあまり詳しくは話せないので、指摘とか頂けると嬉しいです
- メインフレーム
- HPE NonStopサーバ
- Stratus FT Server
- オープン系: クラスタ
- オープン系: 負荷分散(シェアードナッシング)
- クラウド/仮想環境: Live Migration
- ソフトウェア: Jakarata EE/EJB
- ソフトウェア: Oracle RAC
- ソフトウェア: Erlang/OTP
- ソフトウェア: Cloudで良くありそうなMSAや非同期キューをベースとした無停止デザイン
- まとめ
- 参考リンク
メインフレーム
- ホスト機/汎用機とも。国内の富士通とか日立はIBMアーキテクチャをベースにしている。独自進化部分もあるけど。NECとかユニシスはまた別アーキテクチャ。
- 金融や行政系を中心に現在もたくさん利用されている
- Fail Softに基づいたハードレベルの冗長化や障害時の切り離し
- 単独マシンで信頼性を実現。ハードウェアレベルのクラスタ機能もあるのでさらに複数マシンを使ってさらに信頼性を上げることも可能
- ハードウェアのエラー時の処理をハンドリングする仕組みを用意している
- 逆に言えばアプリケーションエンジニアがハードウェア障害を意識する必要がある
- z Systemなんかは現代でも最高スペックのマシン。DockerとかLinuxを動かすことも実はできる
- 単独メーカで全てを製造しているのでシステム全体で一貫したセキュリティモデル/信頼性モデルが構築できるのは魅力
HPE NonStopサーバ
- Tandem)とも。銀行のATM、証券売買、クレジットカード処理と言ったメインフレーム以上の無停止性が要求される金融トランザクションを中心に利用
- Fault Tolerantに基づいたハードレベルの冗長化や障害時の自動切り替え
- 複数マシンを束ねてシステムの信頼性を実現。(少なくとも現代では)ソフトウェアが中心の信頼性
- プロセスペアという仕組みを使いメインのプロセスをサブプロセスで監視し問題があれば別サーバで動かす
- CPUは非同期なので性能は出しやすい
- OSは独自。旧来からのGuardian環境だけではなく、POSIX風のOSS(Open System Services)も使えてJavaとかKVSも動く
- Java言語ライブラリやJavaEEなどの内部実装をプロセスペアを発展させたTMF やTS/MPで書き換えてより高速/高信頼な実装を実現している
- 文化的にはOSからパッケージ、アプリケーションまでプロセスペアやTS/MPを活用して無停止性をキープする事を強く意識している
- 専用ハードウェアを必要としていたが、現在はソフトウェアベースになっておりx86はもちろんVMware上でも同等の信頼性で動作する
Stratus FT Server
- Strutsじゃないよ。ストラタス。銀行のATM、証券売買、クレジットカード処理と言ったメインフレーム以上の無停止性が要求される金融トランザクションを中心に利用
- NEC ftServerもあるけど違いは良く知らない
- Fault Tolerantに基づいたハードレベルの冗長化や障害時の自動切り替え。
- 複数マシンを束ねてシステムの信頼性を実現。ハードウェアが中心の信頼性
- ロックステップ処理と呼ばれるCPUレベルで同期しながら処理を実行するので片方が死んでも処理を継続できる
- もちろんHWの交換はシステムを止めずに実施が可能。
- OSはVOS(Virtual Operation System)。Windows／Red Hat Enterprise Linuxなどをサポートしている。VOSとかだとPL/1とかCOBOLで開発
- 専用ハードウェアだが、汎用OSも動くのは魅力的なポイント
オープン系: クラスタ
- ここではOSレベルのクラスタシステム. 今でもx86系で冗長構成を組む一般的な方法の一つ
- Fail Overを基本としたマシンレベルの冗長化や障害時の切り替え
- 複数マシンを束ねてシステムの信頼性を実現
- アクティブ/スタンバイを基本として障害時にシステムを待機系に切り替える。ただしFTサーバとは違い分オーダーの時間がかかり実行中の処理もエラーになる
- OSはUnix/Linux/Windowsなどなど。
- システム構成もシンプルで費用も安いが原理的に無停止稼働ができない
オープン系: 負荷分散(シェアードナッシング)
- ここではロードバランサに繋がった負荷分散のシステム。Webサーバを中心に一般的
- システム全体でFault Tolerant/Fail Softを目指すマシン単位の冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- アクティブ/アクティブ構成なのでサーバ障害時には対象システムを切り離すだけで良いので運用が非常に楽
- WebやAPサーバなどステートレスなサーバでは無停止が実現できるが、DBなどステートフルなシステムには冗長性の観点では単純適用できない
クラウド/仮想環境: Live Migration
- クラウドインフラやVMwareで実施されるHypberviosrレベルの信頼性確保技術。クラウドを支える技術として裏で使われてる
- Hypberviosrを抽象化しているのでハードウェアレベルの個々の故障を見えなくするマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- 例えばGCPの場合は稼働中にゲストOSのメモリコピーを行いVMの停止を極小にすることでアプリレイヤーからは遅延に見える程度の無停止性を実現している
- 信頼性の責務をOSより下のHWとOSより上のアプリケーションで明確に分離できるのが特徴
ソフトウェア: Jakarata EE/EJB
- OSではなくミドルウェアレベルの信頼性。
- 分散アプリケーションを実装しシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- 基本的にはEJBでの信頼性確保技術としてはフェイルオーバーとリトライがある
- フェイルオーバーはエラー時に透過的に別のサーバで実行される。ただしDBなどトランザクションは対応していない
- トランザクション処理はロールバックされるのでリトライを実行することでシステム全体としての無停止性を確保できる
- ただし、実際のアプリ実装ではシステム側でのリトライは運用課題も多いので素直にユーザにエラーを返すケースも多い。システム間接続だと場合による。
- EJBに代わり現在主流のCDIには同等機能はないがMicroProfileのFault Toleranceでエラー時の処理を記述するフレームワークが追加される
- Weblogicなどはデプロイや障害時のフェイルオーバを含めてミドルウェアレベルの無停止を標榜しているが、最近はJavaEEで頑張らずシステム全体の無停止の枠組みにパーツとして組み込むことが主流
ソフトウェア: Oracle RAC
- OSではなくミドルウェアレベルの信頼性。OracleのRAC(Real Application Cluster)を使った信頼性機能。
- DBシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
- RACはシェアードエヴリシングなので障害時にマシンを切り離しても透過的に利用できる
- 特にTransparent Application FailoverはSQL実行中のサーバにて障害が発生した場合、SQL文を他のサーバへフェイルオーバー（リカバリ）を実施
- Oracle DBの専用機能なので適用範囲が限定されるがDBとしての無停止を実現している
ソフトウェア: Erlang/OTP
- OSではなく言語レベルの信頼性。類似の仕組みをAkkaなどはミドルウェア/ライブラリレベルで実現している
- 分散アプリケーションを実装しシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
- 複数マシンを束ねてシステムの信頼性を実現
let it crashと呼ばれる思想に代表される適切に落として素早く復旧させる信頼性確保の方法- Supervisorがプロセスを監視し、問題があったら自動でフェイイルオーバーやリカバリを行う
- 個人的にはNonStopのプロセスペアと少し思想が近い気がする
- 分散システム全体として無停止を担保するが利用できる言語には少し制約がある
ソフトウェア: Cloudで良くありそうなMSAや非同期キューをベースとした無停止デザイン
- アーキテクチャーなんだけど具体的な名前を思いつかないのでフワッとした表題に。名前はまだない？
- クラウドでは無停止システムってどう考えて作るっけ？ と思って良く使われそうな考え方を書いておく
- OSや各アプリケーションではなく分散システム上のサービス単位でFail Soft/Fault Tolerantを実現
- 複数マシンを束ねてシステムの信頼性を実現だが、マシン単位はもはやあまり気にしてない
- 基本的には止まることを前提に回復性に極振りしたデザイン
- MSAにより各サービスの障害時の影響範囲の局所化とリカバリ速度の向上と、可能な限りシェアードナッシングによるアクティブ・アクティブの冗長構成が基本
- 可能な限り非同期/結果生合成を受け入れて、とりあえず信頼性の高いキューに一時保存。失敗したらロールバックとリトライをすることで無停止性を担保
- データはインフラとしては事実上無限のリソースがある事を前提に複数のストレージに同時に書き込むと言うのが基本
- OSとかのレベルの無停止性を実質期待してないのが最大の特徴。体系化/フレームワーク化はもう少し蓄積が必要な印象
- Kafkaだったりk8sだったりIstioだったりなんとかDBだったり実装は決定版がある分けでもまだない
- まだ過渡期だけど思想的にはサービスメッシュなどを活用してアプリケーションからはいくつかの制約を満たせば透過的に無停止性が担保されるはず
まとめ
他にもたくさんある気はするのですが、メインフレーム/無停止サーバ/オープン系/クラウドにおける信頼性確保の基本的な戦略を書いてみました。
意図的にハードウェアレベル、OSレベル、システムレベル、ソフトウェアレベルをまとめて書きましたが実際はこれを混在させてシステム全体の信頼性を組み上げます。銀の弾丸はないと思うのでそれぞれを把握して適切なものを選ぶのが大事ですね。
特にNonStopやftServerといった高可用性サーバは存在自体がマイナーですが、アーキテクチャ的には結構面白いので誰かの詳細な解説があると教えて欲しいです。
クラウドでももちろん無停止サービスは実現できますが、高可用性サーバを使うと商用パッケージからOSライブラリに至るまで全て無停止を意識しているので無停止サービスの実現が容易というのも魅力ではありますね。 これはNode.jsは実行基盤だけではなくライブラリなども非同期を強く意識しているので非同期プログラミングがしやすい、という話に似ています。
この辺はクラウドでのノウハウやパッケージが揃ってくれば変わってくると思いますが、現状はクラウドでは「アーキテクトが自分たちのシステムに最適な仕組みを個別に考えて実装」というラインです。もちろんk8sをはじめ良いミドルウェアやCloud環境自体の機能も強化されてきてますけど「レールに乗って作れば無停止になる」というところにはまだ至れてません。今後のノウハウ蓄積が大事ですね。
あと、最後に書いてる「Cloudの無停止でありそうなデザイン」は具体的な名前があれば誰か教えてください。MSAは大部分はカバーするにしても無停止システムデザインという意味では要素にすぎない気がするし。
それではHappy Hacking!
参考リンク
テックポエム:010 - 祝！ JDK14 リリース
スライドはこちら: テックポエム 祝！ JDK14 リリース - Speaker Deck
今回はRecord型やパターンマッチングなど目玉機能といえるものが多く入ったリリースでした。
一方で、それらはまだpreview版で通常は利用できないので、今後に向けての中間リリースとしての側面も強いです。
これは、JavaがChromeなどと同じく機能の有無ではなく定期的にリリースをするRapid Releasesのモデルを採用したことによる効果だと思います。
preview版がproductionになったりpreviewで新機能を早くから試せたり、特に今回リリースではないShenandoah GC向けの改修が地味に入ってたりするのは象徴的だなー、と個人的には思います。
TLDR;
テックポエマーの10min IT News! - 2020/03/15 - 「ARMメニーコア時代/技術系ポエムにLGTMしないで」 を公開しました
動画で使ったスライドはこちら: Speaker Deck
BGMを付けたり開始までの待受け画面を作ったりとか少し工夫をしてみました。
なのですが、ついでにボイスチェンジャー回りの設定を弄ったせいか音声周りが声が小さくて音質悪い感じに。。。 とりあえずアーカイブ版を作るにあたっては多少音量調整をしてみたのでマシになったはず。この辺の加工が私の技術の限界です. orz
今回はQiitaのLGTMへの変更が個人的には印象的でした。と言うのも、この動画のタイトルの元ネタの「技術系ポエムはQiitaに書かないで！」というテーマが改めてフォーカスされました。これからQiitaがどこに向かうのかはとても興味深いです。
今週のサマリ
- ARMが超メニーコアに突入
- 英銀行のMonzoのマイクロサービス
- Qiitaの「いいね」が「LGTM」に変更。でも意図に対してUIが疑問
動画中の引用記事
Product Update
- 「Istio 1.5」リリース、「Istiod」やEnvoyの拡張モデルを導入 | OSDN Magazine
- 「Firefox 74.0」リリース、米国ユーザー向けにDNS-over-HTTPSがデフォルトで有効に | OSDN Magazine
- 「Unicode 13」リリース、新たな言語・文字・絵文字が追加され文字数は14万3800種類に | OSDN Magazine
- PowerShell 7が正式リリースされました ｜ Developers.IO
AR新興企業のMagic Leap、身売りを検討か
Amazonがレジなし決済技術「Just Walk Out」を小売店に提供開始
- Amazonがレジなし決済技術「Just Walk Out」を小売店に提供開始 - GIGAZINE
- Amazon Go Gets Going, Announces OTG Will Use Its Just Walk Out Tech
64 Core? 80 Core? 超メニーコアARMの登場
- ARMを採用した80コアのサーバー用プロセッサが元Intel社長による「Ampere」から登場、性能はAMDの第2世代「EPYC」に匹敵 - GIGAZINE
- YouTube - 80 Core 64-bit Arm Processor - A Quick Look at the Ampere Altra
- Amazon's Arm-based Graviton2 Against AMD and Intel: Comparing Cloud Compute
発電所が余剰電力でビットコイン採掘事業
How does Monzo keep 1,600 microservices spinning?
- How does Monzo keep 1,600 microservices spinning? Go, clean code, and a strong team • The Register
- A Guided Journey of Cloud-Native Featuring Monzo
Qiitaの「いいね」が「LGTM」に変わります
Cloud NativeなServerless DBを開発した - 超α版
はじめに
GCPのCloudRunやAWSのLambdaのようなFaaSはアプリケーションのデプロイ先にとても便利です。
一方で、サーバレスなのでストレージを何とかしないといけないのですが、やはりRDBは使いたい。本気の業務システムならここでCloudSQLだとかAWS Auroraが出てきてこいつらは問題無くこれらのサーバレスなアプリから接続できます。
ただし、高い。大事なことなのでもう一度言います。高い。
KVS系は無料枠があるのでそっちを使えば良いですが、やはりRDBが。。。となるととたんに選択肢が無くなります。たんに実行したいのが手元の管理アプリとかだとちょっともったいないですよね？
アプリ側がIaaSやステートフルなコンテナならsqliteを動かすのがこういう用途では多かったと思います。そう、私はサーバレスでもsqlite的なことがしたいのです！
という分けでまずはプロトタイプを作ってみました。
今回はこのプロトタイプをベースに何を作りたいのかを話していきたいと思います。
コンセプト ＆ アーキテクチャー
主なコンセプトは以下の3つです。
まずサーバレスDBという事が必須の要件です。これによってsqliteをローカルに置いていた時のような手軽な運用を取り戻せます。
つづいて、DataStoreやDynamoのようなKVSも良いのですが、やはりRDBは欲しいです。特に既存のOSSを移植したいと思ったときにSQLが使えることは重要でしょう。ただし、用途が実験用または個人向けという事を加味してACIDの完全性は目を瞑ります。
最後にJDBCで接続できること。これは上記とほぼ同じですがRDBなのだからアプリから見たI/FはJDBCであるべきです。RESTやgRPCをアプリから使ってというのは実装が容易そうなのですが既存のライブラリと整合性が無くなるので、完全では無くてもJDBCのサポートは重要と考えます。
上記の3つをコンセプトにして以下のようなアーキテクチャーにしました。
図にすると以下のような感じです。
ストレージの実体は可用性とコストを考えてオブジェクトストレージにしています。これをDBエンジンが都度読み書きする事で永続化しています。
とりあえず超ナイーブに実装したのでSQLのリクエストがある度にDBのフルロードとフルストアが発生しますが、ここは何かしらの工夫が可能が気がします。
現在はDBエンジンはh2dbのラッパーです。Javaだから取り扱い安いというのもありますがh2dbは多くのDBの互換モードも備えてるのでそれも活用できるかもです。
JDBCドライバとサーバはHTTPSの通信なので完全にトランザクションが切れています。なので、必然auto-commitのみの運用になります。WebSocketとか使えば何とかなるかもですが現状は未検討。むしろ性能観点ではgRPCに対応したいですね。
一応、JDBCドライバとして実装してるので以下のようなコードがそのまま動きます。逆に言えば今はこのコードを動かすための実装しかまだしてないですが。。。
var url = "jdbc:serverlessdb://http://localhost:8080/mydb"; Class.forName("cn.orz.pascal.serverlessdb.jdbc.ServerlessDriver"); try (var con = DriverManager.getConnection(url); var st = con.createStatement()) { st.executeUpdate("CREATE TABLE IF NOT EXISTS sample_tbl (name varchar(255))"); st.executeUpdate("INSERT INTO sample_tbl(name) values('Nanoha')"); try (var rs = st.executeQuery("SELECT name FROM sample_tbl")) { while (rs.next()) { System.out.println("rs[1]=" + rs.getString(1)); } } try (var rs = st.executeQuery("SELECT count(1) FROM sample_tbl")) { while (rs.next()) { System.out.println("count=" + rs.getInt(1)); } } }
URLで設定したDBを無ければ新規で作ったりもするので、テストの場合にはかなり便利かと思います。
パフォーマンス
さて、パフォーマンスはどんなものでしょうか？ またベンチマークテストをするレベルではないので単体リクエストを投げたときのログを出します。
2020-03-16 13:05:08.444 JST2020-03-16 04:05:08,443 INFO [ser.profile] (executor-thread-1) tracelog: getBucket(ms): 39.420 2020-03-16 13:05:08.572 JST2020-03-16 04:05:08,571 INFO [ser.profile] (executor-thread-1) tracelog: readDbFiles(ms): 127.543 2020-03-16 13:05:08.579 JST2020-03-16 04:05:08,578 INFO [ser.profile] (executor-thread-1) tracelog: execute(ms): 0.658 2020-03-16 13:05:08.697 JST2020-03-16 04:05:08,697 INFO [ser.profile] (executor-thread-1) tracelog: storeDbFiles(ms): 117.519 2020-03-16 13:05:08.697 JST2020-03-16 04:05:08,697 INFO [ser.profile] (executor-thread-1) tracelog: executeQuery(ms): 293.730
これはデータ件数が数件しかない非常に小さなデータだという事に注意してください。それでもデータのREAD/WRITEに240msくらいかかっており処理速度の大半を占めています。 データが大きくなったときにどういう傾向になるのかとか、実感速度としてどの程度遅いかは今後の計測ですね。まあ、原理的にはあまり期待できない気がします。
リードレプリカを作るのは容易なので、リードヘビーなアプリなら読み込みをスケールさせることも理屈上は可能な気がしますが、それもデータサイズが影響してくるので真面目に作るとシャーディングが必要になりそうです。
きっと真面目に作るとSpannerクローンみたいになってくるのでそこを真面目に作ってはダメでしょう。
今後の展望
まずはちょうど欲しかったREDMINE的なチケットシステムを実装しながら機能を拡充して、標準的なAPIは実装させておきたいです。
その上で、既存のMetabaseみたいなOSSツールをサーバレスに改造してみたいとは思ってたので、そういった場合のコンフィグ格納先として使えると良いなぁ、と思ったり。上手くいくかは分かりませんが。
あと、管理APIは実装しないとですね。DBを消したりとか。
sqlite3的な気軽なDB運用はやはりサーバレスになってもしたいので、しばらく開発は続けてみたいと思います。
それでは、Happy Hacking!
参考
VTuber配信を始めるためのメモ
VTuberというかバ美肉してみようかな、と思ったけど最初は何から始めれば良いかわからなかったので備忘録がてらメモ。随時更新。
準備
アバター/3Dモデル準備
まずはアバター準備。セシル変身アプリがVRMを出力して自由に使えるし、VRChatやClusterでも使えるのお勧め。
VRoidとかも有名だけど「絵を描くように３Dモデルが簡単に描ける！」とある通り、絵を描く程度に難しいので私みたいに絵心無い人とか人生ゲームのキャラクターエディット見たいにパーツを選んでカスタムしたい人向けではないので注意。使いこなせる人にはとても良いツールなんだろうけど。
Vカツ
パーツ選び系のキャラクタエディットツール。高機能かつ多彩な感じでとてもいい。
難点はニコニコ立体にVRMをあげての利用になるので、5000円という値段はともかくVRChatなどVirtualCast以外の環境で使えない。。。 あと、2.0はどうなったんだろう？
セシル変身アプリ
パーツ選び系のキャラクタエディットツール。簡単にかわいいキャラクターが作れてVRMも出力できる神アプリ。
デザインのベースがロリ系に寄せてあるので、それ以外の造形を作ろうとすると結構センスがいるのかも？ 継続して開発されていてカスタムできる部分も増えどんどん進化中
ニコニコ立体 ＆ シードオンライン
VirtualCastで利用するためにはVRMはニコニコ立体かシードオンラインにアップロードする必要がある。Seed onlineでは他にもVCIで作られた小物やスタジオが無料ないしは有償で入手できる。
Booth
創作系、とくにVR関連では鉄板の販売サイト。いろんなギミックが仕込まれたアバターも販売してるので、気に入ったアバターを買うのも一般的。カスタム可能なものもある。
スタジオツール
アバターを動かす場所。VRChatのようなVR SNSから中継してる人も居るし、Clusterのようにより勉強会などイベント開催に向いたものもある（今はVR SNSとしても利用可）。
VirtualCast
特にニコニコ生放送と連携したツール。凸機能があるので他の人が配信に参加することもできる（＃OFFには普通にできる）。
他にもYoutubeにも対応している。個人的にはVRスタジオ/VR SNSの中では一番UXがこなれていると思し、配信にも便利。リングメニューは素晴らしい。でも自分のスタジオを複数個もったり保存出来るともっと良いのだけど。。。
なお、アバターの追加方法はこちらを参照。
配信ツール
VirtualCast単体ではYoutubeやニコニコ生放送に配信が出来ないので、配信ソフトと組み合わせる必要がある。配信ソフト自体はVRとか特に関係無いのでWindowsやMacで動くソフトを選べばOK。
N-Air
OBSのカスタマイズ。ニコニコ動画に上げるのに便利な機能が付いてるのでニコニコで使うならこっちがお勧め。
OBS
Youtuber/VTuber問わずほとんどの人が使ってる配信ソフトの定番。シーン切り替えや複数のWindowの合成など何でもできる。ゲーム実況とかライブコーディングとか。
ボイスチェンジャー
バ美肉は最近は地声の人も多い（まあ、最古ののじゃロリおじもだが）けど、声を弄りたい時はソフトウェアボイスチェンジャーが便利。恋声とバ美声が有名。あと自分で変声してる両声類という人達もいる。すごい。
うちの構成はこんな感じ。
YAMAHA NETDUETTO
仮想サウンドデバイス。マイクやスピーカーのように振る舞う仮想デバイスでこいつをハブにしてマイク、ボイスチェンジャー、OBSやVirtualCastなどのソフトを繋ぐことが出来る。ボイスチェンジャーはNETDUETTOを出力先に指定することで、OBS/VirtualCastからみたらこいつがマイクなどの入力機器に見える。
バ美声
現在使用中。比較的低遅延なので歌とか歌わない限りは問題無く使えると思う。これより低遅延を求めるとたぶんハードウェアエンコーダー使う必要があると思われる。割と良い感じ。
RTX Voice
フリーで使えるノイズキャンセルツール。バ美声とも組み合わせて使えるのでお勧め。
配信について
配信のやり方やTips。正直自分は精進が全く足りない。。。
スライドの準備
自分の配信はプレゼンスタイルなのでスライドを使います。VirtualCastでスライドを作るには以下のホワイトボードを利用すると簡単に出来ます。
ただ、サーバに画像をアップロードする必要があるので、手前味噌ですがPDFやPPTXをアップロードすれば自動で画像に変換してURLをJOSN形式で返すサービスを作りました。VirtualCastでプレゼンをしたいときには便利だと思います。
配信待ち画面/シーン切り替え
Yotubeやニコニコ生放送では配信ボタンを押すと配信がすぐ開始されます。ただ、VirtualCastとニコニコ動画を接続しようとすると配信の後にバーチャルキャストを起動する必要があります。 その他にも単純に開始してから少し準備をしたい時とか、時間ピッタリに始めるけどある程度参加者が集まってから配信できるように少し早めに配信を開始したい事は良くあります。
そういうときに画面の連携を切っておくことも可能ですが真っ黒な画面を流しておいても味気ないので「シーン切り替え機能」を使って待ち受け画面を作ることが出来ます。
下記はOBSのやり方ですがN-Airでも手順は同じです。
BGM
待受け画面とかあるいは配信中にBGMを鳴らしたいこともあると思います。動画編集ツールで足したり配信ツールで足したりすることも出来ますが、一番簡単なのはシンプルにデスクトップで音楽プレイヤーを鳴らす事です。配信の著作権には要注意。
下記では多くのフリーBGMを公開されています。
また、あえてVR上で完結してみたいという欲求もあると思います。VirtualCastの場合は下記のVCIを使う事でVR上で音楽を再生してそのまま配信に乗せれます。
VRスタジオ内でも音が聞けてめっちゃ便利！
サムネイル
Youtubeとかに動画として挙げる時にはサムネイルがあった方がたぶんよい。作るのは簡単でお勧めは適当なシーンのスクリーンショットをとってそれをパワポに貼り付けて文字を乗せる。DTPとかちゃんとしたソフト使うべきだけど、私のようにセンス無い人はどうせ高度なこと出来ないからこれで十分。センスが欲しい。。。
動画編集
動画の前後の余計な待ち時間をカットしてトリミングしたり、長時間動画の切り抜きを作ったり、そもそもテロップ入れたいとかいろんな欲求も出てくるはず。簡単な処理はYotube上でアップロード後にも出来るけどとてもエンコードに時間がかかる。どうせ、VRする人は良い感じのGPU詰んでるのでPCでやった方が速いのでお勧め。
古き良きAviUtl や、検索したら良く出てくるFilmoraもあるけど簡単な事をしたいのならShotcatが便利だった。エンコードプロファイルに「Yotube」って項目もあるしね。QtベースだからLinuxなイメージがあるかもだけど普通にWindowsでもMacでも問題なく動作するしUIも普通の動画編集ソフトみたいな感じ。kdenliveも良さげだけどとりあえずShotcatを使用中。
テックポエマーの10min IT News! - 2020/03/09 - 「コロナウイルスと電子書籍、パスワードを竜破斬に」 を公開しました
今回からWebページのスクショを直接じゃなくて、一度パワポに張り付けて画像に変換してみました。サイズが統一されて見やすくなったはず。
日本もアメリカもコロナウイルスの影響で大混乱というのが今週の傾向かな。動画では言い忘れたけどAmaoznやMSのシアトルオフィスも全面リモートワークになったりと動きが加速してる感じ。
それにしても電子書籍が紙のコミックを売り上げベースでついに超えたのは嬉しいですね！ 合算したコミック全体の売上も増えてるし。
今週のサマリ
- QuarkusいっきにJavaのメジャーフレームワークへ。あれHelidonは？
- コロナウィルスで様々なイベントが中止。一方、Zoomなどのリモートワークは進む
- 電子書籍のコミック売上がついに紙のコミックを超える
- パスワードを竜破斬のカオスワーズにするとセキュア
動画中の引用記事
BeyondCorp? ゼロトラスト？ VPNを超えていけ！
- TL;DR
- はじめに
- BeyondCorp << ゼロトラスト
- ゼロトラストセキュリティ
- リモート接続のセキュリティ3要素
- VPNの問題点
- ゼロトラストによるセキュアな通信
- ゼロトラストの企業ネットワーク
- コンテキスト認識アクセスコントロール
- ゼロトラストによるVPNの問題点の解決
- ゼロトラストの課題と展望
- まとめ
- 参考
TL;DR
- BeyondCorpはゼロトラストの実装の一つ。ゼロトラストは超乱暴に言えばポストVPN
- 社内も信用出来ないとして社外と同じ方式でNWを組む
- HTTPSによる暗号化と次世代認証基盤を使ったCAACによるアクセスコントロール
- FWによる境界からIDによる境界へのパラダイムシフト
はじめに
ニコ生でゼロトラストについて話したので、こちらは解説記事となります。
動画で利用したスライドはこちら。SpeakerDeck
コロナウイルスによりまさかのパンデミックによるBCPが発動されている今日この頃。皆様はいかがお過ごしでしょうか？
出社してる人、自宅からリモートワークをしている人、色々だと思います。
リモートワークと聞いてまず最初に思い浮かぶのがVPNですね。VPNで社内ネットワークに接続して社内と同様にアクセスできる。リモート接続の鉄板ですね。
ですが、VPNにもそれなりに問題があり、最近はゼロトラストセキュリティという言葉も聞くようになりました。あるいはGoogleはVPNを辞めてBeyondCorpを採用する事で、VPN詰まりも無く在宅勤務できる仕組みがあるとか。
私も初めて「Google VPN辞めたってよ」的な話を聞いた時には「？？？？」という感じだったので、今回はゼロトラストセキュリティあるいはBeyondCorpに関して説明していこうと思います。
BeyondCorp << ゼロトラスト
現時点での私の理解では、という前置きは付いてしまいますがBeyondCorpとゼロトラストは言っている事は同じです。
もう少し言い換えるとGoogleでのゼロトラストの実践がBeyondCorpです。このあたりはDevOpsの実践の一つがSREなのと同じですね。
歴史的にゼロトラストが流行る前からGoogleが対応していた名残だと思います。なのでGCPでBeyondCorpを見かけたらゼロトラストの事と思えば良いですし、GCPな方はゼロトラストをBeyondCorpと理解すればだいたいあってます。
ゼロトラストセキュリティ
Zero Trust SecurityとZero Trust Networkの差は前者の方が少し範囲が広く後者は企業ネットワーク基盤の話をしている認識です。とはいえ大きな差は無いでしょう。
スライドにも書いている通り、トラディショナルな企業ネットワークは「信頼されたネットワーク」の存在を前提に成立しています。
たとえば、DCの内と外はFirewallでがっちりと守ります。しかし、その中はどうですか？ DC内の通信にFirewallやIDS/IPSはどこまで適用されるでしょうか？
DC内は安全という前提でVPNでDC内に繋ぐ事で社内システムにアクセスができます。多くの社内システムは外部にさらされることを想定していないので認証が弱かったりDDOS攻撃のような基本的な対策もされていません。
このようにネットワークを内と外で分けるのがトラディショナルなネットワークの基本的な考え方です。しかし、これは現代では十分ではありません。
ゼロデイ攻撃、巧妙なウイルス、ターゲッティング攻撃、悪意のある利用者と様々な理由により境界となるFWを超えた攻撃がなされるのは常識です。
そのため、内部のアクセスであっても常に疑い認証をしっかりとする事が重要です。結果として「社内と社外を区別せず常に如何なる場所からのアクセスであっても検証する」という同じコントロールが実現できます。
リモート接続のセキュリティ3要素
リモート接続には様々な方式が存在しています。TELENT, VNC, SSH, そしてVPNです。
かつてはSSHの利用も多かったとは思いますが、今はVPNが主流だと思います。VPNにはDC間を繋ぐSite To Ste(S2S)VPNとClient to Site(C2S)がありますが、リモート接続に使うのはC2Sですね。
一言でVPNと言ってもその特性や実装はプロトコルや製品で大きく異なりますが、企業向けのリモート接続でC2SのVPNに要求される機能は以下でしょう。
Authentication/認証
VPNクライアントを立ち上げると社内アカウントのIDとパスワードを入力します。場合によってはMFAで生体認証やスマートカードを使うケースもあります。いずれにしても利用者のIdentityはVPNにとっても非常に重要な要素です。
Device Trust/機器認証
これは厳密には認証の一部ですが分かりやすいのであえて切り出しました。BYODとしてどんなPCからもリモート接続可能というケースもありますが会社から提供されたPCのみから使えるケースも多いと思います。これを実現するためにSSL証明書など端末にインストールする方式をとります。。これによって安全なPCかどうかを判定するわけです。
Encryption/暗号化
VPNの最も基本的な機能と言っても良いでしょう。Virtual Private Networkというだけあってあらゆる通信パケットをラッピングして暗号化するのがVPNの本業です。これによりインターネットを経由したアクセスであってもセキュアな通信が実現できます。
セキュアな通信としてはインターネットVPN、広域IP網を利用したIP-VPN、そしてVPNじゃないけど専用線があり良く比較に上がると思いますが「セキュリティ観点では」実質これらは同等です。
IP-VPNや専用線を使うのは単に通信品質の保証やレイテンシなどパフォーマンスのためです。セキュリティ強度としてはSSLを利用したインターネットVPNで問題なく、そこは製品選定の時には誤解しないように注意が必要です。価格は圧倒的に違いますしｗ
リモートアクセスとしてのVPNは上記の要素によりセキュアな通信を実現しています。逆に言えば上記の3つを満たせばVPNでなくてもセキュアな分けです。
VPNの問題点
つづいてVPNの問題点について考えていきましょう。大きく以下の３つがあります。
キャパシティ/パフォーマンス
まずはキャパシティです。VPNは基本的に社内のDCに接続しに行くのでVPN GWが必要になります。
これはリモート専用の設備なのでリモート利用者向けにキャパシティプランを組み立てますが、そこがネックです。1万人の会社で1万人がリモートアクセスするケースはまれでしょう。せいぜい1000人分のキャパプラをします。
これが災害時には5000人とかに跳ね上がり混雑を引き起こします。BCPを考慮した予算確保は現実的には結構大変なので現実的な課題です。
またパフォーマンス観点でもVPNは暗号化された通信なので原理的に遅いというのもありますが、そもそもDCを経由した通信を実現する技術です。DC内にアクセスする場合なら良いのですがSaaSの場合は不必要な経路を通ることになります。地理分散してない場合は海外からの接続では大きくレイテンシーが劣化してしまう懸念もあります。
特にVDIを利用している場合は通信がTCPに固定されてしまったりVDI側の最適化方法が上手く使えない場合もあるので通信が劣化しがちです。
このようにVPNにはいくつかのオーバーヘッドがあり、キャパシティプランも個別に必要なものとなっています。
適切な制御の難しさ
VPNは基本的に社内に中継ポイントを置いてそこからアクセスする方式なので追加のACLを入れない限り社内と同様のアクセスポリシーが適用されてしまいます。
つまり良くも悪くも「リモートからもVPNを繋げば社内と同じ完全に同じことができる」ということです。
例えば「リモートからメールなどのシステムにはアクセスしたいけど、顧客管理システムにはアクセスさせたくない」というケースがあったとします。
この場合、VPNで振られるIPで顧客管理システムの手前にあるFirewallで止めるしかありません。さらに「基本的には禁止なんだけどAさんだけは顧客管理システムにアクセスさせたい」という要件もあり得ます。この場合は、AさんのIPに対してさらに例外的な設定をする必要があります。
VDIを利用しているとより複雑で、社内と社外で同じVDIを使うとリモート接続かどうかがそもそも判定できません。そのため社外用のVDIを別に用意するケースも考えられます。
また、これらの制御はあくまでACLなので、通常のアクセス権を管理しているフロー(アカウント管理とか権限管理とか)とは異なります。異なる作業を組み合わせるためオペレーションや業務フローが煩雑になりがちです。
これらの課題は既存のDCの設計次第ですし、実現できなくはないのですがコントロールのコストが高すぎるためあまり細かな権限管理は行われていないのが実際だと思います。
一貫したセキュリティポリシーの適用が困難
VPNの最大の問題として「VPNに繋がないと社内セキュリティが適用できない」という事が言えます。
これは簡単に言えば社内ProxyやPaloAltoなどの次世代FW、あるいはEDRやデバイス制御の適用外になるという事です。VPNを使わない場合は通常のインターネット経路の接続になってしまい、トラフィックを管理することが出来ませんし、DC内にあるセキュリティツールからリモート管理することもできません。
このようにオンプレミスのセキュリティと相性が極めて悪いのです。そのためリモート接続用のPCのセキュリティが下がってしまいます。
これに対応するためにリモート接続用のPC向けに別の製品を入れるなどでセキュリティを担保する事もありますが、これもコントロールがケースバイケースになる事で複雑化してしまい望ましくはありません。
他にも接続先が社内システムなのかSaaSなのかで適用するセキュリティ製品が異なる場合もあります。たとえば、社内システムにはVPN必須だけど社内でも利用しているSaaSはVPN無しでも行けてしまうとか適切に設定をしていないと脆弱性になりますし、社内のセキュリティルールが複雑化して矛盾が発生してしまう元です。
このようにVPNでは「オフィス内とリモート接続」「DC内とSaaS」といった複雑な環境に対して一貫したセキュリティモデルを適用することが困難です。
ゼロトラストによるセキュアな通信
それではゼロトラストでどのようにセキュアな通信を実現するかを見ていきたいと思います。
ゼロトラストは既に述べているとおりFWではなく認証システムを基盤としたセキュリティモデルです。そのため、認証という点では問題なく実施できます。
例えばAzureADを使った場合であればセキュリティキーやスマホの認証アプリ、あるいは指紋認証などのFIDO対応のMFAを適用しパスワードレスな運用もできます。デバイス認証に関してもIntuneなどの組み合わせて実現できます。
大きく異なるのは通信の暗号化です。VPNでは全ての通信を暗号化していました。これは当時としては必要だったのですが現在はWebアプリケーション化も進んでおりHTTPSも当然利用されています。VDIのようなアプリケーションの場合でもSSL/TLSには対応してます。その為、暗号化自体は個々のアプリケーション側に任せるというのがゼロトラストの考え方です。
時代が、暗号化を常識とするようになったので、結果としてリモートアクセス基盤としてはVPNのように「全てを暗号化する」という責務から解放されたわけです。
ゼロトラストの企業ネットワーク
ゼロトラストにおける企業ネットワーきうの形を見ていきましょう。
「トラディショナルな企業ネットワーク」と異なり信頼できるネットワークは無くなり、認証基盤により各ユーザ/各アプリ毎にチェックを行います。
ネットワークとFWがセキュリティ境界だったトラディショナルなモデルから、IDを境界にセキュリティを担保するようになりました。
後述するCAACにより社内なのか社外なのかというのはあくまで多要素の一つとして利用はされますが、根本的にはどこからアクセスするかとかどこにアクセスするかは関係なくなります。
これにより社内も自宅もDCもSaaSも関係なく同一のシステムでアクセスコントロールが掛けれるようになります。
コンテキスト認識アクセスコントロール
引用: [Japan Tech summit 2017] SEC 010
Context-Aware Access Control (CAAC) ではコンテキスト----すなわち「誰が」「どこから」「どのデバイスで」「どのアプリに」アクセスしようとしているかを判定して、それらのリスクを計算した上でアクセス可否を判定します。
これにより同一の人が自宅からアクセスするときと社内からアクセスする時で認証の制御を分けることが出来ます。VPNが苦手だったロケーションによる複雑な制御がゼロトラストでは容易になります。
このようなリスクを動的に計算する仕組みはルールベースの認証だけではなく、機械学習などにより「いつもと違うアクセスに対して追加の認証を要求する」と言ったリスクベース認証も可能です。
たとえば、出張等で海外に行っているときや不正アクセスが多くリスクが高いと判定された時は追加の認証が自動で入ったりする、などが例としてイメージしやすいかと思います。従来のRBAC + Network ACLではこのような柔軟な制御は苦手なのでCAACになって実現しやすくなったことの一つです。
ゼロトラストによるVPNの問題点の解決
ゼロトラストでは。VPNと違いリモート専用の仕組みという分けではなく社内も社外も同じ仕組みです。その為社外向けの特別なキャパシティプランは不要です。つまり社内向けに1万人の設計をしたら1万人分のリモートアクセスのキャパシティは持っているわけです。
また、CAACを基本とした次世代認証基盤により社内も自宅もDCもSaaSも一貫した仕組みでアクセスコントロールが出来ます。もう、リモートの場合は特定のIPセグメントを振って、それに対してACLを入れて。。。と言ったことは不要です。
アクセスコントロールだけではなくエンドポイントセキュリティに対しても一貫したコントロールが可能になります。
CAACの機能として「どこから」を判定する必要があるため基本的にこの認証基盤はインターネットからアクセスされる場所にあります。つまり、社外からの門番として存在していたVPN-GWの代わりに認証基盤自体がGWになってるわけです。
そのため「VPNに繋ぐ」というクッション無しにダイレクトにSaaSへの認証やアクセスを制御できます。これによりEDRやEgress Filterでもクラウドベースのセキュリティ製品を利用しやすくなります。これらを使いVPNを経由せずインターネットから直接端末を保護することで、社内にいる時と同様に社外のセキュリティをコントロールできます。
このようなデバイスレベルでのセキュリティ、End to Endのセキュリティがゼロトラストの特徴です。
半面、認証基盤に要求されことは多くAzureADやCloudIdentityあるいは各種セキュリティ大手ベンダーやベンチャーが出しているIDaaSを使うのが無難でしょう。
ゼロトラストの課題と展望
セキュリティと言えば「めんどくさい」「生産性が下がる」というのがイメージだと思いますが、ゼロトラストは珍しく生産性とセキュリティの両方を向上させる概念です。
ゼロトラストで社内と社外を区別しないというのは結構大きくて、これは「スタバのようなカフェ」と「会社の社内ネットワーク」を同じセキュリティレベルとしている事です。逆に言えば会社のネットワークセキュリティを普通のWiFiレベルまで下げれます。
ただ、万能ではなく課題というか注意点もあります。
たとえば、ネットワーク的には同一とはいえ社内と社外では監視カメラや入退室のセキュリティーカードといった物理セキュリティが異なるので通常は区分する必要があることも多いでしょう。
また、WebアプリケーションならHTTPSやIDaaS対応は容易ですが、C/Sベースのレガシーな仕組みだと難しい部分もあります。
特にサーバとの通信が平文の謎プロトコルだとクライアント側に結構手を加えないと実現は難しいでしょう。新規に作るものやHTTPS/SAMLに対応したデスクトップアプリなら問題はありませんが。
そういったこともあって、まだまだVPNを利用される事は多いと思います。しかしSaaSが増えてきた現在ではゼロトラストの観点でセキュリティを組んでいくしかありません。基本はWebアプリケーションにしてC/S型のデスクトップだけVDIやアプリケーションストリーミングを利用して対応する必要があるかと思います。
レガシー対応としては、既存のWebアプリケーションをゼロトラストに対応させるGoogleの「BeyondCorp Remote Access」やMicrosoftの「Azure Application Proxy」が有効です。C/SにはCitrixの 「アプリケーション仮想化」などが使えるかと思います。
まとめ
今回はBeyondCorpを皮切りにゼロトラストに関して説明してみました。改めてまとめるとポイントは下記です。
- BeyondCorpはゼロトラストの実装の一つ。ゼロトラストは超乱暴に言えばポストVPN
- 社内も信用出来ないとして社外と同じ方式でNWを組む
- HTTPSによる暗号化と次世代認証基盤を使ったCAACによるアクセスコントロール
- FWによる境界からIDによる境界へのパラダイムシフト
それにしても震災のタイミングではじめてDRという考えが「現実的なシナリオとして」定着しましたが、今回のパンデミックでBCP観点でのリモートワークも現実的な検討になるんでしょうか？
災害は喜ぶことでは決してないですが、雨降って地固まるというか塞翁が馬というか少しでも困難を糧にできれば良いなぁ、と思います。
あと、余談ですがAzureADはADのマネージドクラウド版ではなく、まったく別の認証基盤でむしろADFSに認証機能が内蔵されて進化したものととらえた方が良いので名前に惑わされないように注意しましょう。
それでは、Happy Hacking!
