サーバの状態管理に構成管理ツールをもっと活用した方がいいんじゃないか

最近、サーバの状態管理に対する世間の関心が高いように思うのだが、状態管理をちゃんとやっている所とやっていない所の差がつらい時がある。 そこで、いわゆるProvisioning Toolchainに従い、考えてみる。

(Provisioning Toolchainについては、インフラ系技術の流れ - Gosuke Miyashitaを見てください)

Serverspec at July Tech Festa 2013より引用

まず、Bootstrappingで言えばDocker。Dockerfileからコンテナをビルドできるし、できたコンテナはリポジトリで管理できる。状態管理としては素晴らしい。Vagrantあたりも手軽に同様のことができる。

次に、Configuration。Chef、Puppet、Ansibleあたりが有名。 私は現在のプロジェクトでAnsibelを利用しており、その恩恵を十分に受けている。

で、Orchestrationでは、Capistranoとか。私は、AnsibleをOrchestrationでも使っている。Ansible便利。もっと頑張れば、Consul・Serfとか組み合わせてもいいかもしれない。

あとは、Herokuに見られるような、Gitを利用したデプロイとかもいい。Pushするだけでデプロイできちゃうみたいな。

でも、上記のようなプロビジョニングをできてない人もたくさんいるはず。 そんな時は、せめてサーバ上にあるファイルをGitなりSVNなりでバージョン管理すればいいのにと思う。

サーバの状態管理を意識していない所は、そもそも、サーバにあるファイルを構成管理できていないとかよくある。

GitにしろSVNにしろ、ファイルの追加・更新→コミット→アップデートを組み合わせれば、最初に書いたようなプロビジョニングのようなことは普通にできる。サーバまたいで同期とればOrchestration風になるし。

Provisioning Toolも大事だが、その前に構成管理をきちんと行うことも非常に大事。

【書評】世界を変えた確率と統計のからくり134話

  • 統計にまつわるキーパーソンが、統計の黎明期(1500年あたり)から、時系列に紹介されている。
  • 人物の紹介はもちろん、歴史的背景や、統計に関する用語の解説が載っている
  • 時系列に話が進むので、統計に関する考えの成り立ちがとても分かりやすい
  • 話の中に、ルーレット・カード・サイコロ等、ギャンブルがよく出てくる。最近も、将棋やチェス、クイズで、機会学習が盛り上がっている。やっぱり何かの勝ち負けに統計が絡むとエピソードとして面白い。
  • 本の中で、「本書で活躍する主な数学者・統計学者」として1501年から現在までの人物が、38人登場している。 統計を学ぶ際に目にする人物は軒並み登場するが、ベイズの名前はその年表に無い。話には出てくるのだが。やはり、一般的な統計からは異端なのだろうか。
  • この本を締めくくる、134話目がかっこ良すぎるので、最後に引用する。生きた伝説と呼ばれる、インドの統計学者、ラオの言葉。
  • 「すべての知識は、突き詰めていけば歴史である。すべての科学は、抽象的に見れば数学である。すべての判断は、その根拠を問えば統計学である。」
  • 「すべての判断は、その根拠を問えば統計学である。」だなんて、かっこいい。


【書評】 システムテスト自動化 標準ガイド

書籍名、概要

書籍名:システムテスト自動化 標準ガイド

概要:

448ページ、全15章で構成される、システムテスト自動化に関する情報が網羅された書籍。システムテスト自動化について、良いことばかりではなく、よくある問題や解決方法、実際の事例を織り交ぜ、丁寧に書かれている。この本を読むことで、テスト自動化に対して以下のようなことが期待できるかと思います。

  • 自動テストについて体系的に理解できる
  • 既知の内容に関して思考を整理できる
  • テスト自動化を人に説明する際の参考になる

以下で章ごとの内容紹介します。

テスト自動化のコンテキスト

第1章

テスト自動化のイントロダクションが説明されている

テストケースがどの程度良いかを表す属性

テスト自動化を行うにあたり、テストケースの有効性を判断するための目安が列挙されている。実行・デバッグがいかに安く行えるかや、テストケースの発展性は特に重要かと思います。テストケースは一度書いたら終わりではなく、プログラム修正に合わせて、継続的な保守が必要ですし。

スティングスキル

テストの品質だけではなく、コストも考えましょうということ。どの範囲まで自動化するかは悩みどころ。バランスは大事ですね。

テスト自動化

自動テストは何度も実行することで、手動テストよりも経済的になるというのは真実ですよね。CIツール等を活用して、効率的・継続的に自動テストを行うことが大事です。

開発ライフサイクル全体のテスティング活動を助けるツール

ライフサイクルの段階ごとに、10のテスティングを補助するツールが列挙されている。断片的には知っていたり、使っているが、このようにまとめられると、体系的に理解するのに役立つ。

テスト自動化の利点

テスト自動化の利点が8個列挙されており、最後は「より完全なテスティングを少ない工数で実施できると、品質と生産性の両方が高まる。」とまとめられている。利点のうち、「市場に早く提供できる」はリーンスタートアップでも大事ですし、「自信が持てる」は私も精神的な安心を得たくて自動化することも多いです。

テスト自動化に共通する問題

自動テストに対する過剰な期待や、組織の理解が足りないのもよくあると思います。この本ではこれらの問題に対する内容もたくさんあり、参考になります。

スティング活動

自動テストでの活動は、手動テストでも共通だと思いますが、比較は、自動テストでは、自動比較になると思います。手法を慎重に検討する必要があると思いますが、本書では「第4章 自動比較」で詳細に説明されています。

キャプチャーリプレイテストはテスト自動化ではない

第2章

キャプチャーリプレイテストは私はあまり行わないので、さらっとしか読んでいない。このテスト行う方は参考になると思います。

スクリプティング技法

第3章

スクリプティング技法

スクリプトを5種類に分別して技法の違いを説明している。

テストスクリプトにこんな種類があるのは知りませんでした。これらの情報は普段あまり見かけないので、本書みる価値あると思います。技法の種類と違いは、「3.4 まとめ」で表になってます。

自動比較

第4章

自動比較について、様々な視点で分析している。この章はとても参考になりました。比較対象、比較方法、比較の粒度、比較のタイミングについて詳細に解説されている。この章はこの本のハイライトの一つかと思います。自動テスト実行と自動結果判定は別物ですよね。

比較で分からないものは何か

比較の結果、全て正しいことを保証することは難しいが、制限付きならば使えると書かれている。このあたりは棲み分け難しいですね。

テストの感度

センシティブなテストとロバストなテストについて書かれている。テストの目的に応じて使い分ける必要があると思います。勉強になります。

比較のガイドライン

シンプルさ、標準化、分割、効率性の他、「センシティブなテストロバストなテストのバランス」も大事だと書かれている。ここはとても大事なので、ぜひとも実際に本読んで欲しいです。

テストウェアアーキテクチャ

第5章

テスト資料、生成物、二次生成物等の、テストを実行するために必要なものや、テストにより生成された物を、どのようにまとめ、変更や保守を行うか説明されている。

前処理と後処理の自動化

第6章

前処理、後処理が自動化に向いている理由と、それぞれの処理内容が説明されている。自分の感覚だと、テスト自動化を行う際は、クリーンな環境が必要なため、この辺は既に自動化されていることが多いと思います。思考を整理するのに良いかもしれません。

保守性の高いテストを構築する

第7章

新機能の実装時や、既存機能を変更する際は、テストの作成や変更が必要になる。自動テストをメンテナンスする際の要素として、 テストケース数、量、実行時間、相互依存性、複雑性等が説明されている。そして、テストケースのあるべき姿として、柔軟な形式であることや、デバッグが簡単であること、可能な限り独立していることが述べられている。メンテナンスコストは一般的に手動よりも自動の方が顕著とも書かれており、メンテナンス性を上げるにあたり参考となる。

メトリクス

第8章

メトリクスは各種ツールクラウドサービスでも取得できますが、個人的に、この章はとても勉強になりました。この章では、投資利益率 (ROI)、Glibの法則、欠陥検出率 (DDP)、欠陥修正率 (DFP)、テスト自動化の属性、ユーザビリティ等が紹介されており、テストを客観的に評価する際の指標として、とても参考になると思います。テストを評価するのって結構難しいんですよね。特に、効果を説明できないと、先進的な技術に取り組むことができない、自分のようなSIerにもおすすめの章です。

その他の課題

第9章

この章は、今までの章で説明できなかった様々な内容が説明されている。その中でも、以下の内容が特に参考になった。

最初に何を自動化する?
  • とても重要なテスト
  • 全体をサンプリングするような広範囲なテスト
  • 手軽に自動化できそうなテスト
  • 最も早く見返りの得られるテスト
  • 実行頻度の最も高いテスト

小さく始めることは大事かもですね。あとは早く効果が得られそうなのとか。

テスト自動化ツールの選択

第10章

この章は、技術的な話ではなく、現実的な話ですね。

  • テストに関する現在の問題の識別が必要
  • テスト自動化ツールの購入を含めた解決策の評価
  • ツールの導入にかかるコストの妥当性を示す必要がある

政治的な話や、デモンストレーションについても書かれています。お固めの企業等、周りを説得したい人は特に参考になると思います。

組織内へのツールの導入

第11章

タイトルの通りです。意外とこういう内容は書籍に載ってない部分ではないでしょうか。組織に対するアプローチを知りたい人は多いに参考になると思います。エンジニアもこういう知識あると話進めやすいかもですね。

Seleniumで保守性の高いテストスクリプトを構築する

第12章

Selenium IDESelenium WebDriver等が紹介されている。Selenium知らない人はとっかかりとしていいかもしれません。知ってる人は特に真新しい情報ではないと思います。

キーワード駆動スクリプト実践事例

第13章

データ駆動スクリプトやキーワード駆動スクリプトが紹介されている。キーワード駆動スクリプトとして、有償のSilk Testで.NETが例として取り上げられている。私はもっぱらOSSのLLを使っているのでさらっとよんだだけ。私はRuby使うこと多いですが(最近はTurnip+RSpecとか)、キーワード駆動スクリプトっていう表現はあんまり聞かない気がしますね。コードの自動生成はいいかもですね。テンプレートエンジンとかDSLとか。Rubyで自動生成はあんま聞かない気がしますが、今度探してみるか。

CI (継続的インテグレーション)

第14章

この章は技術的な要素強くて結構面白かったです。最先端とまではいきませんが、それなりに面白いと思います。

サーバー構成管理ツール

Puppet, Vagrant, Chef, Ansibleが紹介されている。私は昔Chefでしたが、最近はAnsible使ってます。このツールひとつでブートストラッピング・コンフィグレーション・オーケストレーションをいい感じでまかなえて、気に入ってます。

Immutable Infrastracture

ここも触れられています。言葉の説明だけって感じです。

CI(継続的インテグレーション)

Jenkins、CircleCI、Travis CIが紹介されている。普通にメジャーなとこですね。TravisCIは少し多めに紹介されてます。CIのとっかかりとしてはいいんでないでしょうか。そんなに深くないので、実際にCIするには、別の情報源もみる必要あるかもです。

状態遷移に着目したテスティングフレームワークの構築事例

第15章

ソフトウェアの状態遷移に着目してテスティングフレームワークを設計、構築する例が載ってます。JUnit4や、Groovy、JGraphTが紹介されてます。フレームワークの構築例なので少しエッジ効いた内容です。

おすすめ書籍

継続的デリバリー

継続的デリバリーを扱ってる書籍自体少ないですが、この本は特に内容充実してます。DevOpsにも通じると思います。自動テスト周りも丁寧に説明されています。

チーム開発入門

DeNA,株式会社シャノンの開発陣による執筆。CI(継続的インテグレーション)、デプロイの自動化(継続的デリバリー)、リグレッションテスト(回帰テスト)等が載っています。

Jenkins と Docker を組み合わせクリーンな環境で複数バージョンのテストを同時に実行する

  • Docker は chroot に近い使い勝手で高速にコンテナを立ち上げることができる。

  • travis-ci のように複数バージョンの同時テストが Docker を利用することで簡単に実現できる。

  • Jenkins と Docker を組み合わせると常にクリーンな環境でジョブが実行できる。

image

第8回Jenkins勉強会で「Jenkins with Docker」というLTをしました #jenkinsstudy - Yahoo! JAPAN Tech Blog

エンジニアの評価基準、そして危機感を簡単に得る方法。|クックパッド CTO 橋本健太に訊く![後編]

  • エンジニアの評価を、①評価主体的な問題の発見と解決、②誰にも負けない分野を仕事で活かせているか、③設計はシンプル、④社外開発者全体への貢献度で行っている

  • キャリアプランに関して「もっとこんな方向性もあるよ」「実は会社的には今やるべきことは…」と、ドバイスをリーダーが積極的に行なうこともよくある

  • 「1年前の自分と今の自分を比べて、変化していなければいけない」という、危機感を煽ることは効果が高い

image

エンジニアの評価基準、そして危機感を簡単に得る方法。|クックパッド CTO 橋本健太に訊く![後編]│CAREER HACK

エンジニアを成長させる、たった6つの指針。|クックパッド CTO 橋本健太に訊く![前編]

  • クックパッドでは、数年前から「エンジニアのあるべき姿」を明文化して6つの指針を示してきた

  • 指針では、エンジニア同士が尊敬できるエンジニアの特徴「エンジニアのあるべき姿」ような内容を明文化している

  • 6つの指針は、①ユーザ視点、②技術の使い方、③誰にも負けない分野、④他のエンジニアに貢献、⑤嘘ごまかし・妥協はナシ、⑥議論のための議論はしない

image

エンジニアを成長させる、たった6つの指針。|クックパッド CTO 橋本健太に訊く![前編]│CAREER HACK

未来予測を支える技術とPivotal/Mongo、Groonga (2)

  • 楽天インサイトテクノロジー・サイバーエージェントさくらインターネット等のパネリストの面々からの率直な「ツッコミ」があった

  • Groonga族の概要と最新情報の発表があった。Groonga 3.1.0、Mroonga、Rroonga 3.1.0、Droonga 0.7.0。

  • Groongaの後継となるGrnxxの構想が発表された。Groongaの制約や課題を解決し、インメモリ化を行う。

Database Watch(2014年1月版):未来予測を支える技術とPivotal/Mongo、Groonga (2/2) - @IT