  |
はてなキーワード: 分散ファイルシステムとは
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムは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 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
