dshimizu/blog/alpha

とりとめのないITブログ

July Tech Festa 2018 へ行ってきたのでその自分用メモとか雑感とか

Tech イベント

July Tech Festa 2018 へ行ってきたのでそのメモとか雑感とかを書いておく。

雑感

聞きたいセッションはたくさんあったが会場Aにずっといてそこのセッション(以下)を聞いていた。

SREという役割の隆盛を受けてか、今年はシステム運用管理×ソフトウェアエンジニアリングによる問題解決やマネジメント系の話が去年より増えていた気がする。 インフラエンジニアというとサーバ管理とかハードウェアやネットワークをごちゃごちゃやるような感じをイメージされることも多かったけど、最近だとk8sでいい感じのコンテナ環境作ってたり、GoとかPythonとかでいろんなツールを作って運用改善しました、みたいな人も多い。必要なスキルセットの幅が増えてきたというかインフラエンジニアの領分が変わってきているのを感じた。クラウドの台頭で、そこまで低レイヤの深い知識を求められることが少なくなってきているのもあるんだろうな...(前から言われていることではあるが)

A00: Preferred Networksの機械学習クラスタを支える技術

PFNさん大村様による基調講演から始まった。 PFN社での大村様の主な取り組みとしては、機械学習向けのクラスターの開発・運用とPythonで書かれたオープンソースの深層学習向けフレームワーク「Chainer」を開発とのこと。 分散深層学習でChainerを簡単に使うための「ChainerMN」をクラウド(AWS)やk8s上で簡単に使うためのツールを作られているらしい。

事業として機械学習をやられているのは知っていたが、IoT方面で色々な取り組みをしていたことは知らなかった。

上記の深層学習の研究を支えているのがChainer。(使ったことないから詳しいことはワカラン...)

自社の機械学習用クラスタ環境で MN-1 と呼ばれているとのこと。 合計1024個のGPUを利用でき、内部のデータ通信にはInfiniBandが用いられたクラスタ環境。凄まじい... 構築・運用はNTT PC Communications社、NTT PC Communications社(NTT Communicationsの子会社)にも協力いただいているそうだ。

クラウド全盛の時代でPFNが自社で機械学習環境を持つのには以下の理由があるとのこと。

  1. 計算力が競争力の源泉と考えれており、それを自社で保有しておきたい。それによって大きな成果をあげたい。かつてクラウドのGPU枯渇もあった。
  2. 日々の研究で息をするように使える環境を持ちたい
  3. ChainerMNで使うInfinibandのような高速な通信環境はクラウドでもなかなか使えない
  4. 上から下まで(HW〜アプリまで)のスキルを自社で持つことの重要性

こういった明確で強い思いを持った上で自社でこのような規模の環境を構築・運用されているケースはなかなかないと思うので素晴らしいと思った。

機械学習クラスタは全てオンプレではなく、CIツール(jenkins)やHarbor(Private Docker Registy)はAWSで、インターンの方など用にボット経由でインスタンスを立ち上げるAzureの環境もあるとのこと。 オンプレのクラスタ環境は、ストレージはGlusterFS/HDFS、コンテナはDocker、コンテナオーケストレーションツールはApache Mesosとk8sを別々で利用、その上で内製のジョブツールが動いているような構成。k8sやJupiter Hubも利用者がアクセス可能。その他監視はData Dog、ソースコード管理にGHE、そして全てSSOでログイン可能とのこと。

内製のジョブスケジューラは、利用者がローカルのGitリポジトリでコードを管理し、GPUをいくつ使うとか、どのライブラリが必要かとかを全て定義したものをCLIでジョブを投げるとDockerイメージが起動し、そこでジョブが動くうようになっているとのこと。必要な学習データはAPI経由でアップロードできるようになっているらしい。

色々なツールが乱立しているが、PFNのクラスタ環境利用者にはITエンジニア以外にも色々な分野の研究者など、さまざまなバックグラウンドをもった方々がいらっしゃるとのことで、そういった非IT系の研究者の方々にとってはDockerやKubernetesというのは関心事ではなく、自分たちの実行したい計算がおこなえる環境があることが重要であるため、そのために利用者のリテラシーレベルやニーズにあわせていくつかの実行環境・操作方法を準備しているとのこと。

後半は実行される深層学習の処理に関するノウハウやMesos/k8s経由でのGPUやInfinibandの使い方などに関する説明が多かった。こういった環境にはご縁がないためテクニカル面での細かい点は聞いているだけではわからない部分も多かったが、色々な利用者に配慮した設計思想については意識したい。

A10: 組織の生産性を上げる役割「VP of Engineering」とは？

株式会社メルカリ 是澤太志様(@sak0620)、株式会社ハートビーツ 高村成道様(@nari_ex)、株式会社Gunosy 加藤慶一様(@s_wool)によるパネルディスカッション形式でのセッション。

「VP of Engineering」立ち上げのストーリー

登壇者様の自己紹介のあと、まずは各社の「VP of Engineering」立ち上げについて。

メルカリ社 是澤様の場合

２０１７年4月にCTOとVPoEの2頭体制になったとのこと。エンジニアが１００名を超えてきたあたりでよりグローバルで戦える、スケールできる組織を目指して技術のマネジメントと組織のマネジメントに分離したそうだ。

ハートビーツ社 高村様の場合

２０１０年くらいは30人規模の会社でCTOがVPoEの役割も担っていたが、現在は70人ほどに増えてそれに伴いやることが単純に増えて来たので分離されたとのこと。

グノシー社 加藤様の場合

ハートビーツ社同様もともとCTOが同一の役割を担っていた。ただ、メンバーの悩みといったマネジメントに取られる時間が増えて来たため、マネジメントの責任を別な人がやるようにすることで、各々が得意な部分に時間を使えるようにしたとのこと。加えて事業・サービスの責任者をプロダクトごとに複数人、別に設けているとのこと。

VPoEとCTOの役割の違いは？

メルカリ社 是澤様の場合

技術のマネジメントと組織のマネジメントでまずは別れる。 CTOは技術的提案と意思決定、その成果に責任を持つ。技術のレベルを引き上げたり、経営に技術的優位性を与えるのがCTOの責務。是澤様としてはアップルのスティーブ・ウォズニアックが理想的とのこと。経営に対してインパクトを与えるほどの技術力でプロダクトを作り出した点が理想的。 VPoE/組織のマネジメントは範囲が広い。エンジニアリングに関するあらゆる成果に責任を持つ。ただ、責任範囲が曖昧。経費精算の仕組み化など、エンジニアリングに集中してもらうためになんとかしないといけない面倒臭いことはたくさんある。これらを改善するためにエンジニアリング側のマネージャーに協力してもらう必要があり、VPoEが何人居ても足りないが、CTO、及び経営の成果を最大化するための課題に取り組む、仕組み化して解決する、といったところをエンジニアの視点を持って経営レイヤに食い込んでいくことがVPoEの責務。

ハートビーツ社 高村様の場合

CTOは技術方針・ビジョンを掲げる、社内開発・手を動かすところもやられている他、技術的な広報活動もやらているそう。 VPoEは組織マネジメント、具体的には人の配置・裁量・育成・報酬・強化・退職など。あとは事業の運営。そして文化の浸透、醸成。人が増えている中でハートビーツをどういう会社にしていくかといったことを打ち出す。 まだ、CTOがビジョンを描くことに集中できていないかもしれない。CTOが技術方針、先見性を持って技術を選ぶ、VPoEは選んだ技術の執行責任を持ち、価値にするというところに責任を持つべきなので、もう少しVPoEで巻き取れるところがあるかもしれないとのこと。

グノシー社 加藤様の場合

グノシー社の技術力というものを無理やり表現すると、技術の幅・深さと、チーム開発力、メンバー層の暑さ・数・リードして教えられるエンジニアを増やすといった2つに分けられるとのこと。その上で、CTOは会社の技術方針に責任を持つ。VPoEはエンジニアの教育。 チームとしてどう成果を上げていくか、といった点は二人三脚で進めていっている。その中で、どのチームも人が足りない中でどうやりくりしていくか、本人の希望とか聴きながら、会社としてどのプロダクトに力を入れていくか、といったことを踏まえながら人の配置などをおこなったり、エンジニアの教育、チームとして強くなるための目標設定なども考えていくのがVPoEの役割。

VPoEという仕事のやりがいは？

メルカリ社　是澤様の場合

VPoEというよりエンジニアリングマネージメントのやりがいと考えているとのこと。CTOの時に感じていたのはマネージメントが楽しいということ。 ドラッカーとか営業と話してコトラーとかのマーケティングの戦略の本などを読み込んだ時期もあり、それによって可能性を広げた。 色々な法則性を見つけたり、仕組み化したりすることで企業の可能性、エンジニアロールのキャリアの可能性が広げていけるのは面白い。また働き方の仕組みを変えていけるところも面白い。

ハートビーツ社　高村様の場合

色々な人とのコミュニケーションをとることでその人の価値観を知れるのが面白い。人として学ぶところがある。 責任範囲が広いため結果に納得感がある。人の問題が起きた時、これまでは結果を受け入れるしかなかったが、今は自分の責任範囲で見れるため、どういう結果であっても納得感が高い。 組織マネージメントをたくさん勉強することで色々な理論を知れ、それを実践してトライアンドエラーをする活動が楽しい。会議のやり方を変える時は論点を変えてみたり。人の成長のステップの研究者はたくさんいてそれらの理論を実践するのは楽しい。

グノシー社　加藤様の場合

読む本が変わってきた。人事系の本なども読む。 エンジニアをやっていた時は自分自身をどうしていくかという視点が中心だったが、VPoEとなることで周りのエンジニアの成長をどうしていくかというのが中心になりつつある。あとはVPoEがどう評価されるべきかという点や、複数のVPoEを置いてそれを管理する組織を作っても良いかと思っている。

わかって欲しいVPoEの大変なところ

メルカリ社　是澤様の場合

心を強く持たなければならない。リクエストは上からも下からも横からも来たり、自分で気づいてしまうこともある。やるやらないの決断を人に促したりもするので、人は頼るが人のアウトプットを鵜呑みにはしない＝レビューしないということ。レビューしないということは成果に対して興味がないということだと考えている。信頼と信用の使い分けは重要。「お金は大事。仕事はなんでもやる。でも魂は売らない。 by リッチウーマン・プアウーマン」 ビジネスは大事で仕事には色々なステークホルダーがいるが、VPoEとして引けない部分は経営者にもはっきり言う。忖度なく、相手の立場を理解しリスペクトした上で自分の伝えたいことを要求する必要があり、それは辛い。成果のためには鬼になること。

ハートビーツ社　高村様の場合

人と接することにエネルギーを使う。時にはドライに考えてやるべきことに集中すること。パフォーマンスを出すために割り切ること。 他の部署との関わりが増え、そこの責任者と話すことも増えたが、エンジニアと話すときと同じノリで話すとトラブルになることが多い。乱暴な言葉遣いとか。 バックグラウンドが違うことを認識して接することが大事。

グノシー社　加藤様の場合

これからVPoEとしてやっていくので不安について。 フェーズとか規模によってマネジメントの正解も変わって来るのでメンバーには寛容に付き合って欲しい。 マネージャー時代はメンバーの評価とかモチベーションアップに取り組んでいたが、今後はメンバーが思ったような成果が出ないとか人間関係のトラブルなども解決しないといけない思うので心を強く持ちたい。

お互いに聞きたいこと

ハートビーツ社　高村様→メルカリ社 是澤様への質問: メルカリ社規模でも文化の醸成をどうやっているか？

「Go Bold」、「All for One」、「Be Professional」といった言葉をミッションとしており、社外の方でも知っているような言葉を使っているが、こういったところは広報と連携したり、評価制度に組み込んでいる。組織の中でそこに貢献してくれるエンジニアをどうマジョリティーとしていくか、全員を変えるんじゃなくどうマジョリティーにするかを重視している。

ハートビーツ社　高村様→グノシー社 加藤様への質問: エンジニアの採用をどのような体制でやっているか？

エンジニア採用のマネージャーを兼務でやっている。既存採用チームのメンバーはエンジニアとして働いてきた訳ではないので、わからない部分を補完したりエンジニア採用の意思決定を担当し、実務を採用チームがやっているような分担になっている。

グノシー社 加藤様→メルカリ社 是澤様への質問: 全エンジニアとコミュニケーションをとる機会を設けられているか？

今年4月からEM/PM体制と言う仕組みができて、その中でEMが1on1の機会を設けている。他色々検討している模様。

グノシー社 加藤様→ハートビーツ社 高村様への質問: MBA取得されているとのことだが、VPoEに活きているか？

MBAを学んでVPoEになった。体系的に学べるところ、学校にいく必要があるため強制力があるのは良い。 もともと組織作りに興味があったが人間性が伴っていないと当時の上司に指摘され、その中でMBAに出会い、自分に向き合う機会になったのはよかった。 新しい知識がつく訳ではなく、色々な本でも学べるところがあるので銀の弾丸ではないと感じる。

グノシー社 加藤様→メルカリ 是澤様、ハートビーツ社 高村様への質問: マネジメントに加えて新しい技術のキャッチアップが必要と思うが、普段できているか？

メルカリ 是澤様: 平日はまったく時間が取れてない。CTOに教えてもったり社内での技術的な内容で知らないものがあれば調べたりはしている。休日は副業などで勉強している。時間の使い方として技術に関しては休日になってしまう。

ハートビーツ社 高村様: 平日は仕事では12月から全くできてない。休日は学校に通っているので時間が取れていない。たまたま出会ったデザイナーの方と小さいアプリを作ってみたり、他社のエンジニアの方と交流したりすることで補っている。

メルカリ 是澤様→ハートビーツ社 高村様、グノシー社 加藤様への質問: VPoE自身がVPoEの先のキャリアを定める必要があると思うが、今後やりたいことがあればお聞きしたい

ハートビーツ社 高村様: 人の価値を上げていくことが面白いと感じているが、今は自分の組織だけをみているが米国ではバウンダリースパナー(組織や部門を超えてつなぎ合わせる役割)が注目されている。日本ではそんな肩書きはないが、やっていきたい。

グノシー社 加藤様: ある程度軌道に乗った組織に対して取り組んでいくことになるが、それまでの組織に対しても取り組んでいきたい。また、エンジニアリングマネージャーとして取り組んでいくが、そこから会社全体を拡大させていくことに興味をもっている。

A20: Site Reliability・Developer Productivity・技術戦略の取り組み

前半は変化に強いインフラを目指して基盤をk8sに移してマイクロサービス化を進めたということ、中盤はそれによって起こる問題、最後にその問題を解決するために取り組んでいること、に関してお話されていた。 Wantedly Visitは2014年にHerokuからAWSへ移行し、2016年にUbuntu->Core OSへ切り替えとChef->Dockerfileへの移行を進め、2017年にk8sへ移行開始したそう。 Wantedly Peopleはすべて k8s で稼働。当初RoRのみだったがいろいろな言語やフレームワークを選択・対応できるようにできるだけk8sの標準のものを使って構築したらしい。k8sを全然使ったことがないのでk8s標準のものというのが全然わからない...

この辺りは以下の記事にもまとまっている。

MicroServiceの良いところは「技術に特化するものが作れる」、「サービスに合わせたチームができる」ということを挙げられていた。またk8sは親和性が高いらしい。 一方でレギュレーションをしっかり作っておくことが重要とのこと。 インタフェースが明確で、バックアップがとられていて、モニタリングができて、データの一貫性を保てること、壊れないことが大事。

k8s の良いところとしてはスケーラビリティがとりやすいこと、kubectlで基本的な運用可能が可能なこと、一部サードパーティー性ツールも利用しているらしい。 インフラ定義はすべてyamlのManifestファイルを用いており、プロダクトごとに必ずレギュレーションに沿ったManifestファイルがあるので、ちょっと試すときなどはこれをベースとしているらしい また、エコシステムの恩恵を受けやすいということを挙げられていた。Istiom Envoy... Prometheus, Datadog, New Relic...minikube、Helm Chart(ymlのサンプル利用)、クラウドサービス(AWS, Azure GCP)など、k8sで動くものが増えてきている。Communityが活発なのもプラスで、Wantedlyは今後どうしていけば良いのか、という議論の中で、参考文献など出しやすく説得しやすい。

MicroServiceにおける課題

MicroService にすることでいろいろなことが良くなるという話があるが、考えるべきことはたくさんあるとのこと。 この辺りは実際に経験してみないとわからないことで、大きなサービスならではの知見がたくさんあり、マイクロサービスの経験がない自分にとっては参考になる内容が多かった。

O(n)で発生/増加する作業

一個の変更を複数に反映する必要があるものが多数発生。単にk8sの問題ではなくインフラ業務としてそうなりやすい傾向もあるらしい。 SSL証明書の更新とか、スクリプト化しても来年も動くか不明だったり...ELB+ACMで一回で済ませれるように、できるだけO(1)にできないか(1度で済ませられないか)を考えることが必要とのこと。

エラー・インシデントのハンドリングの困難さ

マイクロサービスが増えてくるとインシデント発生時の切り分けが困難とのこと。 MicroServiceごとにパフォーマンスが異なるためのTimeoutやリクエストが詰まるケース、サービスをまたぐデバッグ、リクエストをたたく順番によってエラーになる場合は全部のリクエストを見ることになったり、スパイクがどこからきているかわからないなど。 モニタリングもできているのか？できていたとしてもわかりづらい。一時的に復旧させるにも一人二人では困難でチームでやる必要が出てくる。

管理・取り決め

Internal URL/Global URLの管理、MicroService間のふるまい、インタフェースの明確化

依存関係の問題

どこかの処理が速くなったことで他が耐えられなくなる可能性。 テスト等でもリクエストを送る先のサービスをケアする必要がある。 不要なデータを問い合わせてくるものもある

共通データ

サービスの成長に伴ってユーザのデータなど共通で扱うデータが出てくる。どのデータの問い合わせをどこにするのが正しいのか？といったことを考えるきっかけになったそう。

知見の共有

GitHubにissueとか書いてあるが、それだけだと厳しい。APIの作り方とか利用するOSSの扱い方とかDockerfileの書き方とか 周知させる場所を検討中。

開発環境

マイクロサービス単体で開発することはあまりなく、実際にはAサービス、Bサービス、Cサービスがあり、Aからリクエストを送ってもらわないとBが動かない...といったケースが多く、A,B,CすべてローカルPCに建てる必要がある。 そうなるとローカルPCがスペック的に厳しくなってくる。一から作るのも大変。 各環境でのデータの扱い方も難しい。リストアの順番とかでデータが壊れたり... 他環境が意図しないブランチで動いていたり

ルーティング

サービス分離時にパスレベルで変更したいとき、その時都度NginxのConfigを書くのか？インフラレベルでABテストしたいときは？ネットワーク回りでハンドリングしたいときとかどうするのが良いか? Aサービス→Bサービス→Cサービスというリクエストが発生するサービスでのBサービスの開発の難しさ。リクエスト発生させずらい。

どう解決するか

サイトの信頼性(Site Reliability),エンジニア全体の生産性(Developer Productivity),コアとなる技術基盤(技術戦略)の3つを主軸に、いろいろ取り組んでいるそう。

OKRの明確化、ポストモーテムを実施したり組織として仕組化したり。

A30: 明日から実践できる！運用自動化に必要な「テスト」にまつわる技術

テストツールではなく、正確なインフラのテストをできるようにするかといったお話。 開発/検証/QAといった環境を本番環境と同じスペック、構成のもので用意するのは非常に困難(お金面)であるが、運用系の構築スクリプトやプログラムが本番環境でも正しく動作するのかを事前に確認しておくべきで、オーケストレーションツールを使って本番環境と同等構成のテスト環境を構築してテストできるようにしよう、といったお話だった。 テストのためにオーケストレーションツール(Terraform, CloudFormation)を使って本番環境を複製できるようにしておこう、というのはクラウドをベースにしていればこのアプローチはありだと思うが、オンプレミスだとかなり厳しい...

ポイントとして、以下のようなことを挙げられていた。

  1. 仮想ネットワークの活用、つまり本番環境と同じセグメントを持ったネットワーク環境を作ること、ホスト名に加えて、IPアドレス必要であれば合わせるなど可能な限り同じネットワーク構成として合わせる、ただしグローバルIPなど外と接する部分は異なるものとして、内部構成を一致させること。
  2. サーバのセットアップ手順を含める。Ansibleでもbashでも良いので。用心のためにリポジトリサーバやCIサーバ、ビルドサーバなども含めておく。
  3. マシンイメージを一式作成しておく。packerなどで一式作成しておき、yumなどのパッケージ管理システムでは古いpackageがだんだんinstallできなくなったりするので、自前でパッケージ管理したりイメージで保存しておいた方が良いとのこと。
  4. 上記を1式リポジトリに含めて環境をビルドできるようにしておく

あと、セッションの前半に、環境構築ツールとしてはAnsibleなどがあるなかで、手順的にbashを実行するツールとして bashsteps というものも紹介されていた。

A40: 最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」

SREとして自社でどういう取り組みをしてきたのか、0 -> 1 のフェーズのところでどうしてきたかというところが中心としたお話だった。 資料にもある通り、0からスタートした時の事例や話というのはなかなか聞く機会がないように思う。でもこの0->1へ変わるための取り組みが一番大事であり一番大変なところでもあると思う。

まず目標というか方向性が明確になっているのが大事で、これがないと何をするのが正しいのかよくわからなくなって目の前の業務をやることに意識が向いてしまうように思う。 「ぼくの考えた最高のエンジニアリング 最大限ユーザーへの価値提供に集中できる状態を維持し続ける」という目標に対して、「仕組・エンジニアリングで問題解決しようとする」「人間が頑張って解決しようとしない」という原則のもと、「ユーザーへの価値提供に集中できない状態 減らすための守りの設計」、「ユーザーへの価値提供に集中できる状態 増やすための攻めの設計」という2つの明確な切り口からの取り組みはわかりやすくて良い。

初期フェーズでの、エンジニアリングに注力するという意識、片っ端から勉強、他社のつらみを聞く、(わからないなりに)理論を学ぶ、という取り組み、実際にやってよかったこととしての、ドキュメンテーション、スペックアップ(簡単に解決できるものをつぶす)、ルーチン・コンテキストスイッチを減らすため適用範囲の見極めに注意したうえでの使い捨て前提での自動化用コードを書くというのも、何から取り組めば良いかわからない状態からすれば道筋の1つになりそうで参考になった。

紹介されてた以下の書籍も読んでいきたい。

<li><a target="_blank" rel="noopener noreferrer" href="http://hatenacorp.jp/recruit/operation_engineer">10年続くサービスを、インフラ技術で支える――Webオペレーションエンジニア座談会 - 株式会社はてな</a></li>
<li><a target="_blank" rel="noopener noreferrer" href="https://ihara2525.tumblr.com/post/17029509298/%E4%B8%80%E8%A1%8C%E3%81%AE%E3%83%AD%E3%82%B0%E3%81%AE%E5%90%91%E3%81%93%E3%81%86%E3%81%AB%E3%81%AF%E4%B8%80%E4%BA%BA%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%81%8C%E3%81%84%E3%82%8B">一行のログの向こうには、一人のユーザがいる - ihara2525's blog</a>ドキュメンテーション、モニタリング、自動化やInfrastractuer as a Codeといったところは自分の中でも課題となっているがなかなかうまく仕組化できていないところだったが、それがなぜできないのか何となくわかった。

最初は泥臭く粘り強くやっていくしかないということ、そして結局は技術力だけでは組織や業務を変えれなくて、自分たちにとっての問題とは何か、本来やるべきことは何かを明確にして取り組むこと、それを関係者と意識合わせすることが重要なんだなというのを改めて感じた。

A50: ミランティスが1万台のサーバーを監視・運用するためにInfrastructure as Codeを利用している話

ミランティスのOpsCareというサービスはプライベートクラウドを構築するサービスらしく、現在物理サーバが1万台以上(仮想サーバはそれ以上)で構成されており、また多数のOSSも使っており、厳しいSLAもある中で、それを少人数(2桁らしい)で運用するためのInfrastructure as a Codeについてのお話だった。会社としてはOpenStackやk8sを得意としているとのこと。

構成管理ツールとしては Salt を使っている。コードの管理自体はgitで行い、変更レビューをGerritで、このレビューが通ったものをJenkinsで自動的にデプロイしているとのこと。

監視にはPrometheusを使っているが、大量のプラグインや細かい設定ファイルを扱っていると監視項目の定義忘れや設定漏れ、エージェントへのプラグインの配布漏れが出てきてしまうので、コード化しているインフラ設定群から何の設定が入っているかを読み解くSaltのコードからPrometheus設定ファイルを自動生成しているとのこと。

最初から良かったわけではなく、ここに至るまでにいろいろなことをやってきたとのことだった。

Saltは使ったことがないが、対象サーバの台数が増えてくるとAnsibleでは手に余りそう、というのはよく聞くので(実際にそんな環境に遭遇したことはないが)、Saltのほうがよさそう(適当)。ツールは置いておいても、物理サーバ1万台規模でこの仕組みを作ってうまく運用を回されているところは素晴らしかった。

A60: ソフトウェアで構築する成長し続けるインフラストラクチャとメルカリの挑戦

あとでかく(多分)

参考

dshimizu 読者になる

広告を非表示にする
コメントを書く