じゃあ例えば米国の釘を一本打ち込んだ機械や、あるいは米国製の３Dプリンターを使って製造したモノを輸出する場合は米国輸出規制に引っかかるのかというと、さすがにこれは各国から強い反対もあったようで、米国も譲歩している。具体的には貨物の組み込み比率だったり、米国製技術がどのような理由で規制されているか等々なのだが、結構複雑なのでここでは割愛する。

とはいえ、日本から輸出する場合に米国規制に引っかかるのは①米国産貨物を一定以上組み込んでいるか、②米国で規制されている狭い範囲の技術に基づいて製造されたものか、を気にしていればよかった。①か②にあたる場合でも、それが米国が規制していない貨物や技術であれば米国商務省の許可は不要（EAR99という）だし、せいぜい米国が定めている制裁リスト（DPL、ELなどというものがある。山口組が対象となったリストはSDNという財務省主導のリストなので、また別の話）に輸出先が掲載されているかどうかをみれば、まあクリアできた程度のものだったのだ。

この「EAR対象か否か」というのが、今までの米国規制の限界・閾値であり、その外の世界であれば自由に貿易できていたのが、2022年 10月7日までの世界だった(正確には10月21日施行だが)。

■ここ最近の情勢

ところが、米国規制はここ数年でどんどん先鋭化している。それは、米中の対立もそうだし、従来の「輸出管理」で上手くいかない部分が出てきているからなんだ。

輸出管理は通常は国々の合意に基づき、規制される貨物を各国一致で決めている。通常兵器でいえばワッセナー・アレンジメントという枠組みだったり、ミサイルであればMSG、生物化学兵器であればオーストラリアグループという枠組みがあり、そこに加入している国は、ほぼほぼ同じような規制貨物を定め、その国から輸出する場合は官庁の許可を必要としている。先述のとおり、日本だと経産省、アメリカだと先述のBISとか。

ところが、この枠組みは近年機能しなくなってきている。というのは、とにかく加盟国が多すぎてなかなか決まらない。いくつかの枠組みにはインドや中国も加入していて、その議論には党派性が強く出てしまっている。国連のようなものと想像してもらえばいいかもしれない。おまけに技術は日進月歩で、今で言えば高性能３Dプリンターとかドローンとか、規制すべきものが中々規制されず、時代遅れの工作機械の位置決め精度とかの、ショボい改正を一生懸命議論して決めている体たらく。

■米国の本気

米国はそんな状況に業を煮やし、先述した規制の限界を撤廃し始めている。つまり半導体製造関連で、かつ仕向地が中国であれば、①米国貨物を組み込んでいなくても、②どんな技術であれ米国の規制技術を使って製造したものは、米国輸出規制の支配下に置かれる、ということを一方的に宣言したのだ。

正確に書くと②については対象貨物や米国制裁リストの区分でいくつか条件分岐するけど、たとえばスパコン関係であれば、富士通が日本国内の子会社にメイドイン USAの機器を移そうとした場合でも、いちいち米国商務省の許可が必要となる。そう聞くと果てしなく面倒くさいものとイメージできるのではないだろうか。

■今後中国の半導体開発・製造の援助は全てNG（要許可、ただし許可は下りません）

退職者が続出しているという例の話は、この援助（support）規制が影響しているものと思われる。この規制はEARインフォームという、その名前に反して通知すら不要というよくわからない規制なのだけど、とにかく範囲がめちゃ広い。なにせ規制対象は幅広く「援助」なのだ。もちろん、前述のEAR規制の閾値も関係ない。半導体業界で働くことはもちろんのこと、おそらく機械設備を運送する運輸関係もアウトと思われる。

■今後の見通し

EAR規制の閾値を突破したケースは過去に一度だけあり、それが現在のロシア規制だったりする。

上で述べたEARインフォームが使われ、非米国製品も幅広く規制されている。じゃあこれが日本でなぜ話題にならなかったかというと、ざっくり「米国のロシア規制に賛成し、同様の規制を敷いた国は、対ロシア以外であれば普通に貿易をして良い」という免罪符があるのですな。日本は菅さんか岸田さんの頃か忘れたけど、ちゃっかりこの免罪符をゲットしていた。

だから、今回の中国半導体規制も、米国と同様の規制を敷いた国同士の取引は例外扱いになると思う。たとえば日本と英国アームとか、前述の富士通グループ間取引や援助は、米国の許可なしで普通にできるようになるのではないでしょうか。

とはいえ中国に輸出できないというのはビシっと決まってしまったわけで、今後の日本半導体業界の売上自体は右肩下がりになるのではないかなーと思います。半導体業界を知らないから何とも言えないけどね。

Permalink | 記事への反応(0) | 22:24

2021-12-31

■「ゼロ トラスト ネットワーク」を見据えた抜本的な刷新「VDI と FAT PC の

リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。

最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。

石光直樹，リクルート（2021 年 06 月 04 日）

28 →目次に戻る

ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま

す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め

て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向

けて情報を発信していきました。

　今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整

えていきたいと考えています。

VDI と FAT PC のマルチ環境の実現に向けた検討

マルチ環境の実現は簡単なことではありません。特に FAT PC の環境をどう作るのかについては、時間をかけ

て検討しました。まずは、VDI 導入により大幅に解消された “3 つの課題 ”、すなわち「セキュリティの向上」「PC

管理コストの削減」「働き方変革への貢献」の対応策を FAT PC でどのように実現するか。これが次の課題です。

　「セキュリティの向上」については、高セキュリティ業務にはセキュア VDI を提供し続け、FAT PC に対しては従

来よりもセキュリティを強固にすることにして、この課題をクリアしました。

　続いて「PC 管理コストの削減」では先述の通り、VDI 化によって大きなメリットを得られた部分でした。例え

ば、夜間にパッチを当てたりできるのは、システム管理担当者からすると非常にメリットになります。ところが、FAT

PC に切り替えると、このメリットは享受できなくなってしまうことから、VDI 導入時に刷新した PC 管理システム

を FAT PC にも導入することで一定の解決を図るのに至りました。VDI の導入前に使っていた “ お手製 ” の PC

管理システムでは、パッチ当てや OS 更新などが大変でしたが、最新の PC 管理システムを導入することで、かな

り容易になっていたからです。とはいえ、VDI の管理性には劣ります。この点は、中長期視点でのより良い環境を

目指すために、優先度を下げた部分といえます。

そして「働き方変革への貢献」については、先述の通り、昨今の状況を踏まえると、ビデオ会議をより活用で

きる FAT PC の方がメリットを引き出せるのではないかと考えました。ただし、FAT PC に切り替えることで、い

ままでとはネットワークの流れ方が変わってきます。VDI では、データセンターと端末の間でやりとりされるのは

VDI 画面のデータが中心でしたが、FAT PC ではさまざまな実データがやりとりされることになります。また、社

外などから社内に VPN 接続をする必要があり、その部分がボトルネックになりがちです。その問題に対しては、

ネットワークを再検討することで解決を図ることにしました。われわれの社内ネットワークは VDI に最適化されて

いたので、FAT PC の増加に合わせて拠点のネットワークを増強したり、VPN を増強したりすることを検討しま

した。これにより、働き方変革で求められていたテレワークの要件に対しても十分応えることができると考えてい

たのです。

29 →目次に戻る

しかしながら、この方針は大きく変更を余儀なくされることになります。その理由は 2 つあります。1 つ目はコ

ロナ禍の影響、2 つ目はネットワーク技術動向の影響です。

　社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと

で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって

しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が

難しく悩みました。単純に拠点のネットワーク、特に WAN を増強したとして、使われなくなるなら投資が無駄に

なってしまいます。また、ネットワークにおいては今後のトレンドとして「ゼロトラストネットワーク」が注目されて

きています。おそらく、われわれの目指す「クラウド＆マルチデバイス環境」を支えるネットワークは「ゼロトラス

トネットワーク」になることでしょう。

では、いま「ゼロトラストネットワーク」のようなネットワークを入れるべきなのか。それともいまは暫定構成に

して将来的に「ゼロトラストネットワーク」に移行できるようにするのか――。

コロナ禍で勤務の環境が急速に変わってきていることも踏まえて、この点を検討しなければならなくなりました。

いまもまさに検討しているところで、いまだに完全な結論は出ていませんが、現時点では PC 環境と同じく、将来

的には「ゼロトラストネットワーク」に移行できるように、いまのネットワーク構成を考えるべきと思っています。

変化に対応して、かつ自ら変化を引き起こす

さらに、FAT PC 導入においては大きな変化があります。それは「SAC」（Semi-Annual Channel、半期チャ

ネル）の導入です。

VDI 環境においても「Windows 10」の導入は完了していましたが、「LTSB」（Long Term Servicing Branch※）

を導入していました。頻繁な更新を望まないユーザー向けに作られた、機能更新がない固定的な Windows 10 のモ

デルです。これに永続ライセンス版の「Microsoft Office」を組み合わせて利用していました。

※現在の名称は、「LTSC」（Long Term Servicing Channel、長期サービスチャネル）

これは、「レガシーアプリが存在するので、機能更新がない OS の方がいい」と思っての選択でした。しかし、機

能が更新されないので、OS や Office の最新機能が利用できないなど、将来的には「Microsoft 365」への接続

も制限されるような状況でした。

30 →目次に戻る

　他方、SAC なら OS や Office が常に最新の状態になります。そのため、半期あるいは 1 年に 1 回程度のペー

スで機能が大きく更新されます。IT 部門としては、機能更新時に社内アプリケーションの動作確認などをする必

要があり、PC 管理タスクが増えてしまうことになります。PC 運用コストの増大につながり得るので、VDI から

FAT PC に切り替える際の検討ポイントの一つでもありました。しかし、ここでもわれわれは中長期視点を大事に

しました。

　今後の「クラウド＆マルチデバイス環境」においては、環境が常に最新になる世界が普通になるでしょう。いま

のスマートフォンを見てもそうですが、OS はどんどん更新されて、次々と新たな機能やサービスが利用可能にな

るのがむしろ普通であり、その波が PC の世界にも到来しているのです。PC 運用コストが上がったとしても、わ

れわれもこの波に乗って、ユーザーに対しても新機能やサービスを次々に提供していき、より良く業務を行っても

らえるようになればすてきだなと思いました。

そこで、VDI から FAT PC への切り替えに際して、OS のモデルも LTSB（LTSC）から SAC に変更すること

にしました。PC が最新に変わっていくSAC のような世の中の変化に対応しながら、われわれの環境においても

変化を引き起こして業務を変えることができればと思い、現在、導入を進めています。

VDI 基盤の抜本的な刷新

ここまでは大多数のユーザーが利用することになる FAT PC のことを中心に述べてきましたが、セキュア VDI と

特定用途 VDI として利用する VDI 基盤のリプレースも大きな仕事です。

VDI 基盤リプレースにおいてもいままでの構成を踏襲せず、一からあるべき姿を検討することにしました。まず

検討したのはクラウドの導入です。将来「クラウド＆マルチデバイス環境」になれば、VDI 自体もクラウドのサー

ビスの一つという位置付けになるだろうと考え、クラウドでの VDI 利用を検討しました。

しかし、残念ながら今回クラウド VDI の採用には至りませんでした。われわれの試算ではオンプレミスに比べて

コストが見合わなかった点と、管理機能がまだまだのように思えた点が見送りの理由でした。クラウドはますます

発展する領域なので、今後は状況が変わるかもしれません。われわれも引き続き状況を観察し、一部の環境には

クラウドをトライアル的に導入してみることも視野に入れて、現在、検討しています。

　当面の方針としてオンプレミスの VDI を構築することにしましたが、いままでの構成をそのまま踏襲するような

ことはしませんでした。必要としたのは、運用性やコスト、拡張性に優れたアーキテクチャでした。

31 →目次に戻る

　議論、検討を重ね、さらに比較、検討した上で、われわれは HCI（Hyper Converged Infrastructure）構成

を選びました。HCI はサーバ中心のアーキテクチャで、SAN（Storage Area Network）スイッチやストレージ

を省くことができ、構成がシンプルになり、運用性やコストにメリットがある他、リソース拡張はサーバを追加する

だけでよいので、拡張性にも優れています。われわれが望んでいた点を満たすアーキテクチャと評価しました。

いままでは「サーバ＋ネットワーク＋ストレージ」のいわゆる「3Tier」構成で安定運用できていたので、これを

変えるのは大きなチャレンジでした。とはいえ、チャレンジしないことには運用性もコストも拡張性も勝ち取れませ

ん。「新たなことに挑戦するのが、われわれのエンジニアリングの方針だ」と考え、HCI 構成を選びました。

　加えて、VDI 基盤のデータセンターのネットワークを SDN（Software Defined Network）に切り替える決断

もしました。従来の構成と比較し、運用性や管理性を鑑みて、より優れているという結論に達したからです。また

中長期視点でも、「ネットワークにおける Software Defined の方向性は変わらない」とみています。

Permalink | 記事への反応(1) | 11:27

2020-10-07

■

インフライベントでIaCの話と聞いてSDN、特にContainer-Native Network Functionsの話しようとしたら、枠がないからほかの人に譲ってと回りくどい感じに空気嫁と断られたのいまだに根に持ってる。

IaCの元祖じゃん。NECとかOpenFlowって日本ベンダーがまだ最後の力があったところじゃん。最近話聞かないけど...

蓋を開ければクラウドの上物の話ばかりで、全然下回りの話がなくて、あーやっぱりという落胆と

IaCって言葉やめちまいなよ、せいぜいSoftware/System Architecture as Codeやんけとツッコミでしばらくもやもやした。今もしてる。

Permalink | 記事への反応(0) | 13:23

2017-11-29

■ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。

Scalaにおける最適なDependency Injectionの方法を考察する〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScala リポジトリとして知られています。

ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。

ニコニコ生放送におけるdockerの活用事例:dwango エンジニアブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年から Docker Swarmを採用し始めています。

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ～独自 プロトコル,ファイルシステムの実装もいとわない!～

実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています。

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

OSS の分散ファイルシステムを使用するという目論見が失敗した
自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります。

なぜ彼らはパブリッククラウドや CDN を使わないのか？

触れない話: 事実上全然稼働しなかった CTO 、北の将軍様

パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。

ASCII.jp：niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争原価割れ（総合的サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。