「パブリッククラウド」を含む日記 RSS

はてなキーワード: パブリッククラウドとは

2018-09-19

とある会社機械学習環境を整備しているんだが心が折れそうだ

昨今流行りの機械学習プロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。

グループ全体の規模はそこそこ大きいが、将来単なるアッセブリー屋になることが目に見えている事もあり(今後20年以内には喰われてしまうという憶測もあり)ネットワークLinuxコンテナプログラミングが出来る自分が社内の機械学習、引いてはITインフラ民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。

まずは既存DHCPサーバ名前解決ができないDNSサーバからゲートウェイPCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題デスクトップPCサーバPCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイPCはそれぞれKea DHCPサーバ、PowerDNSサーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題解決することにした。

上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代オンプレクラウド個人的にはエッジクラスタがゆるく繋がるアメーバクラウド?のような呼称があっている気がするが)を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。

とはいえmiekg/dnsを用いてCoreDNS進化版を作るにはリソースが足りず、BINDを用いるにはSA対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品保守サービスが受けられる事から上記2つを選択した。

PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど(言いたかっただけ)、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPIゲートウェイ重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア(とちょっとしたAPIサーバ)をGo言語作成した。

次に世の中のパブリッククラウドOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記APIサーバ連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題解決することにした。

まぁなんだかんだ大企業なのでお金解決する手段もあるが、そもそも高集積ラック搭載GPUサーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。

脱線したが、上記以外にも検証バックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+go簡単フロントエンドサーバを構築し、一人情シス様相を呈している部下のリソース開放、Calico対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。

ここまで寝る時間も惜しんでトップスピードを維持したまま頑張ってきたものの、少し限界を感じている。

特にオンプレクラウド部外者が中々見えてこないものがあり、なんならその見えないもの限界まで吸収できるように、かつ現実的に実現可能ギリギリラインを狙っているのだが、そもそも周りに相談しようとしても何を言っているのか解説する所から始めないといけない。

覚悟はしていたが、ふとした時にとてつもない脱力感に襲われてしまう。

世の中を切り開いてきた諸氏はおそらく一度はぶつかったであろう、この内なる自分の壁をどのように突破してきたのだろうか?

ひたすら孤独との戦いだというのは頭では理解しているものの、突発的にくるこの脱力はいかんともしがたい。

推敲もせずに大変失礼極まるが、コメントをいただければ幸いである。

2018-02-04

ConoHaとかいVPSサービスが悪質すぎる話

時間課金だったり、萌えキャラ結構オススメされている事が多いVPS

ただその実態としては、非常に悪徳業者なので、軽く触ってみる程度だと問題ないだろうけれど、それ以上の利用は強くオススメ出来ない。

TL;DR

ConoHaは契約者に事後報告でサーバ勝手に止めます

諸条件あると思いますが、CPU100%使い切りする処理を継続していたら、事前警告なく、サーバを止められました。

こんな利用をしていたのは、CPUは共有ではないとされていたかなのだけれど…

https://megalodon.jp/2018-0114-1653-36/https://www.conoha.jp:443/faq/vps/

そんな事はお構いなしに停止させられました。それも夜中にね。

サーバ停止の事後連絡はあるけれど、一切の問い合わせ回答はなし

まぁ専有可能リソース100%使い切っても問題はないわけで、サーバの停止に対して不服を申し立てるも一切の応答なし。サーバ停止の事後連絡に対し返信をしようが、サポートへの問い合わせをしようがなしのつぶて。なので、利用者側に過失がある場合はもちろん、事業者側に過失があっても、お構いなしに機械的サーバを事後連絡でばんばん止めてくる。

隠蔽体質バリバリGMOインターネット

CPUの件は、全く以て対策になっていないと思うけれど、以下のFAQをしれっと削除していました。(「basic認証はできますか?」の下にあった)

CPUは共有ですか?

VPSお客様専用の環境ですので、CPUは共有ではありません。

削除した証拠こちら。

https://megalodon.jp/2018-0204-2144-52/https://www.conoha.jp:443/faq/vps/

いやー、せこすぎるよGMO

しれっとFAQ共有のCPUですに書き換えるだけでも十分過ぎるくらい悪質だけれど、不都合からと、いくらなんでも掲載を下ろしてしまうとは…

ちなみに、サポートとやり取りしていたときの内容はこち

>1.VPSサービスにおけるCPUの扱い

専有利用との理解ですが、間違いないでしょうか?

VPSにつきましては共用の環境となっており、仮想的に

専用の環境を割り当てているものとなります

FAQ記載につきまして、ご案内に不足ある記載となり

まこと申し訳ございません。

FAQにつきまして早急に改修を行わせていただきたく存じます

いやー、早急な改修というのは、隠蔽なんですね。GMOすごい。

ところでCPUが共有なのはどんなケース?

一般的仮想環境場合CPUオーバーコミット簡単にいうと、8個のCPUに9個以上のvCPU必要とするゲストOSを起動してしまう)しているケースです。今更、共用云々ということを言ってきたので、この点具体的に聞いてみました。

担当者

いつもご利用いただきまことありがとうございます

ConoHa お客様センターです。

お問い合わせの件につきまして、弊社サーバー仕様

おきましてはご案内できかねるものとなります

VPSにつきましては1台のサーバーリソースを他の仮想サーバー

共有しているものとなります

運用状況によっては収容ホストへの負荷影響が発生する

場合もございます

収容ホストや他の仮想サーバーへ影響が懸念される負荷が

検知されますと、今回のような措置実施する場合もございます

はい、見事に答えてもらえていません。

こちらとしては、契約するときスペックに関わる重要事項だから聞いているのだけれど、どうやら、ご案内できかねる内容らしい。

厳密なことをいうと、HyperThreadingを利用していると厳密には1vCPUで0.5コアの共有割り当てな一方で、1vCPUで1コア近い処理が出来てしまうので影響がなくはないのですが、こちらの件だとHTに配慮して2コアのサーバを借りていたので、それも関係なかったりね…

ということで、優良誤認による契約無効を主張してみましたが、テンプレ文で断られました。

担当者

いつもご利用いただきまことありがとうございます

ConoHa お客様センターです。

お問い合わせの件につきまして、すでにVPSの削除を

実施していただいている状況は確認いたしました。

大変恐縮ではございますが、ご料金の調整につきましては

対応できかねるものとなります

希望に沿える回答ができずまこと申し訳ございませんが

何とぞご了承くださいますようお願い申しあげます

今後ともConoHaをよろしくお願いいたします。

─────────────────────────────

GMOインターネット株式会社

ConoHa お客様センター

FAQ/よくあるご質問 https://www.conoha.jp/faq/

お問い合わせ info@conoha.jp

─────────────────────────────

おかげさまで22周年 すべての人にインターネット

GMO INTERNET GROUP ■ https://www.gmo.jp/

─────────────────────────────

機密情報に関する注意事項:このE-mailは、発信者意図した

信者のみが利用することを意図したものです。万が一、貴殿

このE-mailの発信者意図した受信者でない場合には、直ちに

送信者への連絡とこのE-mailを破棄願います


ちなみに他のVPSだと…

上記の使い方ですが、別に他のサーバに対するクラッキングをしているわけではないし、停止させられることはありません。念のため…(似た使い方をメジャーなA社、G社のパブリッククラウドや、S社のVPSでやってみましたがいずれも問題なし)

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 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

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

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

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

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

ということが分かります

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

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

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

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

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

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

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

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

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

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2016-10-20

俺の年収査定して欲しい

中小SIer 客先常駐インフラエンジニア

26歳3年目 転職を考えてる。

持ってる資格

Linux (LPIC Level 1,2,3)

Oracle Bronze,Silver

基本情報技術者

セキュリティスペシャリスト

統計検定2級

大規模構築経験あり

OSUNIX/Linux系は割と扱える

仮想基盤やAWS,Azureパブリッククラウドの構築経験あり

Ansible,Chefを用いて自動構築できる

ドルは、bind,sendmail,samba,nginx,Apache,Zabbix,LDAPとか

コードはshellとpythonが少々。



麻雀(天鳳)が趣味で、牌譜の解析とかやりたかたか統計勉強して、資格チャレンジしてみた。ついでにpython数学も。どちらも業務で使うことはほぼない。

趣味Webメディア作ってたから、Wordpressサイト作るくらいなら一晩で出来る程度の能力


いまこれで年収300万くらい。安い?普通

このスキル感に年収合ってる?

増田の皆さんに査定して欲しい。

あと転職するならデータサイエンスセキュリティに興味あるのでそっち方面に行こうと思ってる。

オススメ戦略を教えてください。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん