  |
はてなキーワード: SDNとは
数日前にTwitterで話題になっていたアレ。中国の半導体メーカーから米国籍の人々が逃げ出しているというツイートね。
https://anond.hatelabo.jp/20221016140905
当方は半導体業界ではなく、どちらかというとノンビリした業界にいるけど、輸出管理関係の仕事もしているので、何がヤバいのかを書いておこうかなと。
■今までの規制
「米国は世界の警察」という言葉がある通り、米国はありとあらゆる手を使って敵対国に経済制裁等を発動してきた。その中には、米国財務省主導の資産凍結や、米ドル取引を禁止したりする処分があった。
今回の規制は米国の商務省主導であり、一般的に「輸出管理」というときは、普通はこちらの商務省主導のものを指す。
で、普通の国の輸出規制であれば、その国の中で規制すべき貨物を定め、その輸出に監督官庁の許可を必要とする仕組みとなる。たとえば日本は高性能な工作機械を輸出するときは経産省の許可が要る（仕向地によっては許可が下りないことも当然ある）。
ところが、米国の輸出規制というのはちょっと変わっていて、米国から輸出する貨物（技術含む）だけではなく、米国原産貨物を組み込んでいるものも規制対象にしていたり、米国に由来する（米国オリジン）規制技術を使って他国で製造した製品も、米国の輸出規制を受けるとしているんだ。
じゃあ例えば米国の釘を一本打ち込んだ機械や、あるいは米国製の３Dプリンターを使って製造したモノを輸出する場合は米国輸出規制に引っかかるのかというと、さすがにこれは各国から強い反対もあったようで、米国も譲歩している。具体的には貨物の組み込み比率だったり、米国製技術がどのような理由で規制されているか等々なのだが、結構複雑なのでここでは割愛する。
とはいえ、日本から輸出する場合に米国規制に引っかかるのは①米国産貨物を一定以上組み込んでいるか、②米国で規制されている狭い範囲の技術に基づいて製造されたものか、を気にしていればよかった。①か②にあたる場合でも、それが米国が規制していない貨物や技術であれば米国商務省の許可は不要（EAR99という）だし、せいぜい米国が定めている制裁リスト（DPL、ELなどというものがある。山口組が対象となったリストはSDNという財務省主導のリストなので、また別の話）に輸出先が掲載されているかどうかをみれば、まあクリアできた程度のものだったのだ。
この「EAR対象か否か」というのが、今までの米国規制の限界・閾値であり、その外の世界であれば自由に貿易できていたのが、2022年10月7日までの世界だった(正確には10月21日施行だが)。
■ここ最近の情勢
ところが、米国規制はここ数年でどんどん先鋭化している。それは、米中の対立もそうだし、従来の「輸出管理」で上手くいかない部分が出てきているからなんだ。
輸出管理は通常は国々の合意に基づき、規制される貨物を各国一致で決めている。通常兵器でいえばワッセナー・アレンジメントという枠組みだったり、ミサイルであればMSG、生物化学兵器であればオーストラリアグループという枠組みがあり、そこに加入している国は、ほぼほぼ同じような規制貨物を定め、その国から輸出する場合は官庁の許可を必要としている。先述のとおり、日本だと経産省、アメリカだと先述のBISとか。
ところが、この枠組みは近年機能しなくなってきている。というのは、とにかく加盟国が多すぎてなかなか決まらない。いくつかの枠組みにはインドや中国も加入していて、その議論には党派性が強く出てしまっている。国連のようなものと想像してもらえばいいかもしれない。おまけに技術は日進月歩で、今で言えば高性能３Dプリンターとかドローンとか、規制すべきものが中々規制されず、時代遅れの工作機械の位置決め精度とかの、ショボい改正を一生懸命議論して決めている体たらく。
■米国の本気
米国はそんな状況に業を煮やし、先述した規制の限界を撤廃し始めている。つまり半導体製造関連で、かつ仕向地が中国であれば、①米国貨物を組み込んでいなくても、②どんな技術であれ米国の規制技術を使って製造したものは、米国輸出規制の支配下に置かれる、ということを一方的に宣言したのだ。
正確に書くと②については対象貨物や米国制裁リストの区分でいくつか条件分岐するけど、たとえばスパコン関係であれば、富士通が日本国内の子会社にメイドインUSAの機器を移そうとした場合でも、いちいち米国商務省の許可が必要となる。そう聞くと果てしなく面倒くさいものとイメージできるのではないだろうか。
■今後中国の半導体開発・製造の援助は全てNG（要許可、ただし許可は下りません）
退職者が続出しているという例の話は、この援助（support）規制が影響しているものと思われる。この規制はEARインフォームという、その名前に反して通知すら不要というよくわからない規制なのだけど、とにかく範囲がめちゃ広い。なにせ規制対象は幅広く「援助」なのだ。もちろん、前述のEAR規制の閾値も関係ない。半導体業界で働くことはもちろんのこと、おそらく機械設備を運送する運輸関係もアウトと思われる。
■今後の見通し
EAR規制の閾値を突破したケースは過去に一度だけあり、それが現在のロシア規制だったりする。
上で述べたEARインフォームが使われ、非米国製品も幅広く規制されている。じゃあこれが日本でなぜ話題にならなかったかというと、ざっくり「米国のロシア規制に賛成し、同様の規制を敷いた国は、対ロシア以外であれば普通に貿易をして良い」という免罪符があるのですな。日本は菅さんか岸田さんの頃か忘れたけど、ちゃっかりこの免罪符をゲットしていた。
だから、今回の中国半導体規制も、米国と同様の規制を敷いた国同士の取引は例外扱いになると思う。たとえば日本と英国アームとか、前述の富士通グループ間取引や援助は、米国の許可なしで普通にできるようになるのではないでしょうか。
とはいえ中国に輸出できないというのはビシっと決まってしまったわけで、今後の日本半導体業界の売上自体は右肩下がりになるのではないかなーと思います。半導体業界を知らないから何とも言えないけどね。
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。
石光直樹，リクルート（2021 年 06 月 04 日）
28 →目次に戻る
ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま
す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め
て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向
けて情報を発信していきました。
今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整
えていきたいと考えています。
マルチ環境の実現は簡単なことではありません。特に 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 つ目はコ
社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと
で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって
しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が
難しく悩みました。単純に拠点のネットワーク、特に 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）に切り替える決断
もしました。従来の構成と比較し、運用性や管理性を鑑みて、より優れているという結論に達したからです。また
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。
Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
触れない話: 事実上全然稼働しなかった CTO 、北の将軍様
パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
前々からネットワークをちゃんとやっておきたくて、ちょうど勉強する良い機会だろうということでネットワークスペシャリストに申し込んでいた。
結局直前まで勉強できなかったのだけど、数日ぐらい前にやる気が出てきた。
その時に初めていろいろ確認して、午前が2つあることや、午後が記述であることを知った…。
そこからは対策サイトでひたすら過去問をやる。ここ３日ぐらいは本当にずっとやっていて、午前1/2とも7年分ぐらいやった。
問題は午後で、記述式なので難しい。単語を導出するような問題も出るので知識量も必要そう。午後2とか一問で120分もある。
ただ、読んで考えればわかるような問題もあったので半分弱ぐらいの点は取れそうだった。
午後2はやるだけで疲れるので午後1だけやることにした。結局5年分ぐらいは解いたはず。
間違えて昼寝してだいぶ夜遅くに起きたので、徹夜で受けに行くことにした。試験までに半日ぐらいあったので、↑の勉強をしていた。ここの付け焼き刃は午前分には役に立った気がする。
着席したら全然人いなくてびっくり。そういえば、合格率15%っていうのは受けに来てない人は数えないんですね。
まあ午前1は午前1。
午前2も午前2。
休憩時間40分しかないのでコンビニで飯食べるしかなかった。めちゃくちゃ眠かったのでレッドブル飲んだ。
思ったより簡単だった。一応全問解いた。問題1はまあわかるけど細かい単語がわからない、その他は暗記ゲーな場所が少ないこともあり、問題1よりは解けた。
これも事前に思っていたよりは簡単だった。
問題1をちらっとみたらSDNとか書いてあって圧が強かったので、はじめは問題2を解いた。OpenFlowとか構築したことないけど無線ぐらいならわかるだろうし。
しかし、全然単語問題がわからなかったので6割あるか微妙そうという感じだった。
問題1に戻ると、知識が特になくても解けるような問題であることに気づいた。読みさえすれば高度な専門知識がなくても解ける感じ。
結局問題2に20分ぐらい、問題1に90分ぐらい使って基本的に全部埋めて終了。これも7割ぐらいはあると思う。
徹夜というのもあって、とにかく疲れていた。
午前の答え合わせをしてみた結果、どちらも合格していそうで何より。正直試験後に心配になっていたのは午前だったので、これが大丈夫ならまあ受かってるんじゃないでしょうか。
午後は割と運ゲーだと思っていたけど、大体いつも暗記ゲーと日本語ゲーのバランスが上手く取れた問題セットになっているんですね。
悪質勝手登録出会い系サイト スマッシュs-smashmail.com
免許証見せてないのに…
oo様のご利用料金[30円]が未納です。
早急にご清算お願い致します。
会員ID：2****650
--------------------------------------------------------------------
配信停止依頼しようと
問合せからの依頼に応じない理由がサーバ障害であっても、忙しいからであっても、架空虚偽はりぼてフォームとみなして晒しておきますね。
そもそもメール送信依頼なんてしていません。
http://www.s-smashmail.com/menu.php?mc=non_media&sc=5
BARE N BEAR COMMUNICATION SDN. BHD.
NO.40, JALAN BU 1/4,BDR UTAMA DAMANSARA,47800 PETALING JAYA,SELANGOR D. E.MALAYSIA,
役務の内容
役務の対価
料金表にてご確認下さい。
対価の支払方法
銀行振込、電子マネー決済、クレジットカード決済（決済時の為替レートによって請求額が異なる場合がございま す）・後払い決済
後払いサービスについて
商品引渡し時期
ポイント購入時
サービス提供形態の特性上、役務提供後の返金には応じられません。
※当サービスには特定商取引法上のクーリング・オフが適用されません。
連絡方法
tel : +60-1-2303-5393
mail : info@s-smashmail.com
・お問い合わせはmailにて受け付けております。
===== ここまで
