最近行った勉強会そのた201702-03くらい
こんにちは。smallpalaceです。
いつの間にか4月ですね。
2月から3月にかけて出歩いたりした備忘録を失礼します。特にサマってなくて長いのでお時間ある時にどうぞ。
- 2月のansibleのセミナ
Redhatがやってたやつと書籍の出版記念みたいなんに行ったりしました。
Ansible実践ガイド (impress top gear)
- 作者: 北山晋吾
- 出版社/メーカー: インプレス
- 発売日: 2016/12/15
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- 作者: 廣川英寿,平初,橋本直哉,森田邦裕,渡辺一宏
- 出版社/メーカー: 翔泳社
- 発売日: 2017/02/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
片方はビジネス向けっぽくて両方ともハンズオンとかではなかったので行ったあと実際触ってみて書いたのが以下↓
chef使いがAnsibleをちょっと触ってみた前後の感想など - Qiita
- 3月のMyNAのGroupReplication
なんとなく行ってみたら英語だったのでした。QAは通訳してくれてました。
トゥギャッター https://togetter.com/li/1092945
Mattさん(HAがらみの開発者の人)から英語で英語のスライドでInnoDBClusterのGroupReplicationの解説
かろうじてノートにメモれてた内容
・アプリからMySQLRouterへ接続してそこからマスタのGroupに更新する
・スレーブはマスタのグループを見てるのでその時見てるマスタがおちたら自動で違うマスタをみる
・マスタの追加はMySQL-shellでやる、Workbenchにラッパ機能が追加されるハズ
・会場のなかでMySQL-shell使ったことある人は一人だけだった
・mysql.jsで構成情報をjsonデータで渡すこともできるようであった
・マスタを追加するときはデータ量が多いとやっぱり時間がかかるのでスレーブ追加の時のようにdumpデータとるとか
遅くて待ちきれなければOSのsunapshotでどうにかするなど工夫が必要
・ハード的な必要スペックとしてはCPU32～64コア2.5ghz以上、 SSDで低レイテンシなNW（障害を起こさないという意味ではroundtripが5秒以内だが早ければ早いほど良い）
・スライドにshared Nothing ClusterでCrossDataCenterとか書いてあってダークファイバでVPN必須なんですかと聞くの忘れた
・プラガブルなプラグインの機能としてGroupReplicationは提供される
QA
Q.GroupReplicationのレイテンシーに関する要求って、どの程度？A.障害が起きないという基準では、各ノード間で5秒以下。もちろん速ければば速いほど。
Q.（GroupReplicationで）シャーディングの場合、シャーディングキーは必要？ A.現時点では未実装。そうなるだろう、今はなんとも言えない。
Q.既存のグループへのインスタンス追加、再作成に時間がかかる？ A.GTIDで動機をとるので、追いつくことは可能。短縮するためには、今のレプリカの建て方と同じで、バックアップからリストアして、残り差分をGTIDベースで動機させる。
Q.（GroupReplicationは）5.7にPlugInで提供されているが、今後はどういった形で？ A.今後もPlugInの形式で提供する想定。他にも8.0では多くのPluginを提供するつもりで、PlugIn同士の連携強化も考えている
InnoDB Clusterのエラーログがわかりにくいんだけど、もう少しわかりやすくなる？ A. 改良する余地がある。一部は8.0になってしまうかもしれない。
（シャーディングで）複数のインスタンスをまたぐようなクエリの結果をまとめて返すような仕組みは提供される予定ある？ A. 第1段階：ルーターの中にアグリケーション処理を持たせる。第2段階MySQLサーバー自体に持たせる、で考えている。
Q.memcache plugin動く？ A. うごくはずなんだけど、試してない。最近使う人も少ないしｗ
MySQL WorkbenchはGroupReplicationに対応する？ A. 対応予定！
Galeraとの差別化は？ A. (1)運用監視がp_sにまとまってる。（2）MySQLチーム全体で開発することによる中長期的なサポート。(3)GroupCommunicationはP2Pなのでノード追加での劣化起きにくい
Q.ステートメントベースのレプリケーション、将来なくなる？ A. 現時点では廃止する予定なし
RBRにトリガー使えるようになる？ A.社内で何度も議論はしているが、決定している話はない。
5.6まではonline schema changeしたいのでステートメントベース使っているが、今後GTIDがデフォになるであろう中で、どうすべき？ A.MySQL自体でOlineSchemaChange的なものを提供したい。
yokuさんのFablicの質問をsejimaさんが代わりに質問、思わず苦笑い。「現時点では、EOLではない！」。
Q.SingleTransactionでバックアップできない。。 A. 直後のやつは無理だけど、先のやつで対応するだろう。 セーブポイントを追加するとかいってた。
Q.MasterにVIPいる？ A.いらない。マスタがコケたとき、スレーブは勝手に参照先を切り替える。
Mitaさんの「My MySQL Best Practice」
MySQL が得意なのは、OLTP 系ワークロード（DWH系ではなく）
DB選定フェーズを設け、違うものと比較する（本家とMariaどっちがどうとか聞く人にとってはどっちも同じ） どう組み合わせるのがよいか考える MyISAMは同期書き込みしないし破損チェックに数時間かかったりする（Use InnoDB, No more MyISAM）
エラーハンドリングは開発者（プログラマ）の腕の見せ所 リトライしてますか？そのバッチ、再実行できますか？ 障害試験、負荷試験、昇格試験、軽視されがちだけどひつよう
再接続 コネクションプーリングしてても定期で貼りなおして設定更新とか偏りをなおしたほうが負荷高い時間帯にむけて安心
「クエリとクエリの間に重い処理を挟まない」これ、ロック/メタデータロック掴んでる時間も伸びるのでマジで勘弁してほしい
DBAに相談するときは 手段（作業ベース）での依頼ではなく、目的を伝えてほしい！開発者には一部しか見えていないことがあるので、それが最適解かどうかわからない！
会社のすすめで技術じゃなくて英語の研修も5日分くらい受けました。 前よりは語彙が増えて聞き取れるようになったのかもしれないけどまあ自分の中の地を這うような進歩ではありますかね。 なんとか継続可能なようになんか考えようかなと思ってファイアーエムブレムヒーローズの言語をアメリカにしてみたりしたところキャラの声が全体的に低めになってました。 出撃する系の語彙ばっかり増えてもしょうがないので正攻法もなんか考えないといけないですね。
https://matome.naver.jp/odai/2129666088769881601
DMM英会話も安いと聞きました。
- メルカリとはてなの夕べ
sakuraインターネットの宣伝
スパコンをサービスとして使えると CPU３万２千コア、２６２テラのメモリ、InfiniBandでの高速なインターコネクトバンドでつながってて並列計算につかわれる 今まではオンプレだった 「専用サーバサービス」のサービスフレームワークで提供、
クラウドっぽい物理も増えてて良いとこどりのインフラ選びが可能に。
オンプレ一辺倒もサービス利用の流れが来てると。
パネルディスカッション「なぜ専用サーバを選んだのか」
メルカリ×はてなの夕べ
登壇者の人々： メルカリの長野さん（＠kazeburoさん） SREチームというのに属しているそう はてなの渡辺さん（wtatsuru システムプラットフォーム部長
さくらインターネット鈴木さん
さくらインターネット法林さん@hourin コミュニティマネージャー
メルカリ 日本最大のフリマアプリ、USもあり最近UKもできた それぞれ別のインフラストラクチャを使っている 日本は石狩のさくらのDCで、UKはGCPで動いている
ほとんど専用サーバ、IoMeemory/IntelDCCP3700など さくらのクラウドをユーティリティサーバに利用
はてな ２００１年から創業、多くのWebサービスを開発・運用 はてなブログ、はてなブックマーク、マカレル、BrandSafeとか 受託はジャンプルーキーとカクヨムとか DC構成は、ハウジング＠東京、はてなブログくらいからAWSつかいだした ハウジングの移行先で石狩DCを使い始めた
ほとんど仮想化してリソース共有している。高性能なサーバは占有でioMemoryなDBとか
ここからディスカッション
・導入のきっかけ
メルカリそろそろ４年、長野さんはそのうち２年くらい はじめにつくったときさくらのVPSだったらしい 当時のエンジニアがAWSよりさくらに詳しかったためクラウドから専用サーバに移行していった
はてなは使ってたのがハウジング、調達がきつい、ネットワークのパフォーマンスがきつい 自作やめてベンダのやつつかいはじめてクラウドにして、、
・比較するポイント
はてな：AWSつかうようになっててそことさくらを比べて、コストと移転しやすさを、 専用サーバをddでコピーして移動できるというのはメリットだなと バーストが大きいのはクラウドがいいが、そこまでバーストがなくてコストメリットが専用サーバのほうが大きかった
メルカリ：コストの面、パフォーマンスも高い
数字とコストで判断
加藤：使っていただいてありがとうございます。自作サーバのときはてなさんと一緒に勉強会とかしたのでつながりがふかい メルカリさんもVPS担当してたのでなじみがふかい
・専用サーバの導入時の苦楽、物理ならではの問題？
メルカリ：入ってコンソールつかって、は楽だなと思った、物理サーバがなんとなく見える特徴がある なにやってるのかわかりやすかった。
はてな：移行に関してはハイブリッド接続でNWははやく結べるしVMとか楽にできてる それに至るまでにネットワークで苦労する。ハウジングみたいな自由になる環境とくらべると手間がある
・わかいエンジニアは仮想しかしらない？
はてな：サーバみたことない、SSHログインしたことない子もいるし、インフラ強い人もいるしいろいろいる
メルカリ：SREチームには若い人がいないので触ってる人がおおい、新卒とかだと物理サーバみたことがないとか さくらのデータセンタの見学をしたこともある
・導入後の運用について
はてな：ハードの管理がなくなったのは楽になった、ファームウェアのアップデートを追いかけたりもしなくていい DCでファームのバグで落ち続けるとか経験したがそういうのがなくていい
メルカリ：動き出してしまえば楽だし早い。ストレージのI/Oまわりが早いのはうれしい。 動き出す前の、コンソールが使いにくい・重たいとか、一回で大量に発注しないとな時にポチポチがつらいAPIがない さくら：おっしゃるとおりAPIがんばりたい。コンソールからビデオ画面がいじれる
メルカリ：コンソールからRaid組んだりする
パーツ
メルカリ：発注するときにこういうパーツで、というときがある
さくら：あらかじめいうと用意しておくことができる、 IoMemoryが標準だと1.6TBなどで容量がすくないので要望いただいて別料金でご用意してい
・ベンチについて
メルカリ：新しいストレージ周りのものが出たときにそれとAWSとGCPと比較したりしている ioのレイテンシのところは一桁ちがうAWSだとネットワークまわり
はてな：新しいものが出れば比較したりはするし、s-inしてないところで試したりなどしている
メルカリ：撮りためてるベンチマークの表がありひととおりやる
・障害について
はてな：日が浅いので専用サーバでの障害はまだない
メルカリ：3年くらい動いてるサーバはあるが、昔にくらべると圧倒的に安定している 石狩の施設がいいのもあるし必ずRaidになっているしSSDなのでドライブが壊れること自体がない それ以外ではあることはある
さくら：障害にたいするとりくみ、ファームウェアのところが障害に直結するところがある。再起動が挟まるなど コンパネ上でBiOSアップデートできる仕組みを作ったりなど。
・クラウドファースト時代に物理を選択する意味
メルカリ：パフォーマンスとコストの面で圧倒的にメリットがある
小規模でのコストメリット？
メルカリ：単体で同じようなクラウドと比べると安い、高い部分もある使いどころによる
はてな：オンプレでも仮想化しているが、物理でのメリットはカリカリにチューニングしてリソースを使い切れるところ カーネルパラメータチューニングしたり割り込み回りをいじったりしている
メルカリ：バーストはあんまりない。ゆるやかな平準なトラフィック。さばききるには固定で物理がいい。 大きく変動する可能性があるときには仮想がいいと思っているがあんまり使っていない。 IPをたくさんつけたサーバとかは仮想サーバで動いている
はてな：短期的なバースト、あしたトラフィックが10倍になるかもとかはクラウドじゃないとやりづらい
・今後の展望？要望？
はてな：高速なNWの納期が早いとうれしい。ハードのデバイスいじるの楽しいのでつづけていきたい。 ハードの進化についていけるサービスを提供していただけるとワクワクしそう
メルカリ：なるべくサーバの台数を抑えたいのでよりパフォーマンスの高い大容量の高速ストレージでがんばりたい さらに上の容量の大きいものを今度相談したい
さくら：けっこうI/Oに困られている様子なのでお声がけいただいてメニュー化していきたい 大容量というのが最近増えてきている 物理ならではのパフォーマンス出せるというのが要望としておおい
・ききたいこと
メルカリ：石狩と東京の間の通信のレイテンシをどう考えているのかを聞いてみたい
はてな：サービス移転したことあるが一往復なら問題ないと思う。リバースプロキシを移した後に残りの構成を全部うつすとか効率よく工夫している 20～30msecくらいはユーザさんへの影響ないので緩い感じでやっている
はてな：専用サーバに最適化するためになにかしてるのか？
メルカリ：RDSとかクラウドSQLみたいなマネージドサービスはつかわない。生のEC2とGCPをつかう。
さくら：仮想のクラウドつかわれてるが物理のクラウドの選択肢はなかったのか
メルカリ：検討はしたが海外の交渉をしたうえでとかの話だと難しいぶぶんがあるのでAWSつかったりGCはチャレンジしてみようということでやっている UKの話の前にISUCONでGCつかってみてよさそうだということで使ってみようという話に。
はてな：リニューアルとかでサービスの構成みなおしにいいタイミングだと。OSのサポートが終わったりのタイミングなど 止められないので難しいぶぶんがある
さくら：I/Oってどのくらいあったら満足しますか
メルカリ：ioMemoryの速度には満足している、CPUがたりてない。 MySQLのAlterするときにシングルスレッドなのでCPUのパワーがあるとうれしい
はてな：SSDになって普通のようとに関しては何の問題もなくなった。DBまわりはあるだけ使ってしまうので ioMemoryはよいがCPUがたらないようなことに マカレルで時系列DBつかってる
・一般しつもん
マネーフォワード： どのくらいのI/Oだしてますか？
メルカリ：数万はでてる
はてな：数万はでてる、クエリのチューんもある、時系列DBは10万とかもある
１：ラックの物理配置選べないが気になることがあるか？
メルカリ：ありました。実際物理ラックのどこになんだいあるか教えてもらって移動とか対策したことはあった 10Gとかになってからあんまりきにしなくなった
はてな：最近までそんなに大量につかってなかった。10Gうめるほどまだながしてない
さくら：10Gつかいきる感じなったら考えようかと思っています 配置かえて構成をみなおすこともあります
・最後に
メルカリ：石狩のあたらしいやついっぱいつかいたい
はてな：これからどんどん広げていきたい さわってて楽しいのでコストメリットをビジネスにいかしていきたい
さくら：貴重なご意見ありがとうございます。進化させていきたいしハードがみえるところは大事にしていきたい
あと3/30のも補欠18番くらいだったのが当日エクストリームキャンセルで滑りこんできたので別途投下予定です。
あとは技術関係ないところで社内のネゴシエーション研修と会計のテストなどもありました。それぞれ勉強になった気がします。ネゴシエーションは相手の情報8割ということでしたけど情報が大事なのはなにをするにしても同じだなーと思いました。
では長々見ていただいてありがとうございました！！
