BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース LyftがPuppetからSaltStackにリプレース

LyftがPuppetからSaltStackにリプレース

原文(投稿日:2014/08/22)へのリンク

自動車相乗りサービスを提供するスタートアップ企業のLyftは,自社のインフラストラクチャ設定管理ツールをPuppetからSaltStackに変更した。同社のエンジニアであるRyan Lane氏の記事によると,この他にAnsibleも選択肢にあったということだ。最終的には各ツールの使いやすさ,完成度,パフォーマンス,製品を取り巻くコミュニティなどを検討した結果,SaltStackが選ばれることになった。

使いやすさという点では,そのドキュメントの構成や充実度によって,SaltStackは良好な学習曲線を持っている。Ryanの評価では,Ansibleのドキュメントはシンプルで初心者向きではあるが,コードが大規模になった場合にはSaltStackの方が優位だという。設定ファイル(Ansibleではプレイブック,SaltStackではステート定義)を詳しく調べると,いくつかの違いが浮かび上がってくる。Lyftのエンジニアたちは入力,出力,設定の面で,SaltStackの方が一貫性があると考えた。例えばAnsibleが異なったファイル形式(INIファイル,YAML)を使用するのに対して,SaltStackはすべてYAMLで統一されている。ループや条件処理の実行方法も異なり,このロジックをDSLに組み込んでいるAnsibleに対して,SaltStackではPythonテンプレートエンジンであるJinjaを使用する。Ryanと同僚たちは,SaltStackのアプローチの方が好ましいと考えた。さらには,SaltStackの”素晴らしい"イントロスペクション機能も,決定要素のひとつになった。

完成度の面ではAnsibleもSaltStackも十分で,Lyftのユースケースに必要な機能はすべて備えていた。しかしRyanは,SaltStackの方がより機能が豊富だと考えている。さまざまな形式と位置に出力できること,さまざまなソースから取得したエッセンスデータの構造であるピラーをロード可能であること,さらにエージェントとして動作した場合には,リアクタシステムを経由してローカルイベントを発行可能であること,などがその理由だ。

Lyftのユースケースというコンテキストでパフォーマンスを考えた場合,SalStackは特に無変更時の実行速度が速い。

Salt:

  • 全変更時: 12分30秒
  • 無変更時: 15秒

Ansible:

  • 全変更時: 16分
  • 無変更時: 2分

この結果から,RyanはAnsibleのイシューを1件オープンした。同じシナリオでもSaltStackの方がはるかに速い,という理由からだが,現在そのイシューはクローズされている。Hacker Newsでは,Ansibleを開発したMichael DeHaan氏が,Ansibleのパフォーマンスチューニング方法の記事紹介している。ただしその内容は,ユーザ関連の操作の遅さに関するRyanの不満に対処するものではない。

ツールのコミュニティに関しては,SaltStackの方がフレンドリで,その数も多いと判断された。ただしRyanが"Ansibleはmpdehaan(DeHaan氏のGitHubでのハンドル名)がほとんどひとりで書いた"としているのに対して,DeHaan氏は,Ansibleには"現時点で810名のコントリビュータがいる"と反論している。Lyftのエンジニアたちも,SaltStackのコミュニティの方がフレンドリで頼りがいがあり,機能リクエストにも前向きだという意見だった。SaltStackはAnsibleよりも積極的に変更を導入しているが,その一方で"コードの受け入れに関しては厳格さに欠ける場合がある(もっとコードレビューを行うべきだ)"。Michael DaHaan氏がHacker Newsで,"同意できない場合はノーと言います"と明言しているように,これはプロジェクト管理の哲学に関する問題だろう。"これは重要なことだと思います。フィルタリングとテストは,プロジェクトのレベルを決定するものだからです。"

ツールを変更した最大の理由は,コード行数で約10,000という,Lyftの複雑なPuppetコードベースにある。Lyftでは"ビルドして実行"的なアプローチを採用しているため,DevOpsチームとしては,Puppetコードベースは開発者向きではないという考えだ。結局,SaltStackもAnsibleも,1000行程度のコードでPuppetインフラストラクチャを再現することは可能だった。Puppetコードをスクラッチから書き直す可能性にについて問われたとき,Ryanは次のように返答している。

スクラッチから書き直せば,おそらくライン数は大幅に少なくなるでしょう。実行速度も改善されるかも知れません(...)。そうは言っても,Puppetを書き直すのは,あまりにも時間が掛かり過ぎると思います。

Lyftには新ツールに対して,いくつか重要な要件を持っていた。ひとつはマスタ不要のアーキテクチャが可能なことだ。マスタは"不要な障害発生点を増やす上,パフォーマンスを損なう"というのがその理由だ。また,コードは最適化によって変更されることなく,記述順に読み込まれる必要がある。コードは構成管理上の抽象化のあまりない,シンプルなものでなければならない。 横断的な設定(監視など)や,サービス/アプリケーション特有の設定を,別々のリポジトリに格納可能なデザインをサポートすることも必要だ。

InfoQでは以前にも,インフラストラクチャ構成管理ツールを取り上げた連載記事の中で,SaltStackAnsibleを紹介している。この分野の主なプレーヤについて,それぞれ実際のユーザによる仮想討論会も行った。Ryanが指摘している各ツールの長所が,この仮想討論会においても注目されている点が興味深い。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT