タグ

ブックマーク / thinkit.co.jp (35)

  • スローログの集計に便利な「pt-query-digest」を使ってみよう

    今回は「pt-query-digest」を使用して、チューニングしたいSQLがスローログに記録されている場合の調査方法について説明します。 pt-query-digestとは pt-query-digestはPercona社が開発・配布するMySQL用のユーティリティーキットで、「Percona Toolkit」の1つです。最新ドキュメント(2016/3/22現在)はこちらにあります。pt-query-digestの基的な使い方は「スローログをノーマライズ・集計し、人間が判断しやすい形式で出力させる」です。基的にはスローログ用と考えますが、スローログ以外にもジェネラルログやバイナリーログ(mysqlbinlogコマンドの出力を入力する)、パケットキャプチャー(tcpdumpコマンドの出力を入力する)などが利用可能です。 Percona Toolkitのインストール まずはPercona

    スローログの集計に便利な「pt-query-digest」を使ってみよう
  • パイプラインベースのCI/CDツール、Concourseとは?

    CI/CDにおける「Jenkinsおじさん問題」を解決するConcourseとは? 開発をリードするPivotalのエバンジェリストにインタビューし、その特徴や背景を聞いた。 モダンなソフトウェア開発においては、ウォーターフォールモデルではもう限界だと叫ばれて久しい。その理由として、「素早くソフトウェアをリリースできない」「変化に対応できない」などが挙げられる。そこで素早く開発して細かくリリースするアジャイル開発がもてはやされている。また開発と運用をひとつながりのプロセスとして素早く開発と実装を回すDevOpsも、NetflixAmazonなどで実際に利用されていることは業界では常識だ。しかしソフトウェアの開発プロセスをもう少し詳しく見るとコーディングからビルド、テストなどのプロセスをいかに自動化するか? の部分に大きな進展があることに気づく。いわゆる継続的インテグレーション(CI)、継

    パイプラインベースのCI/CDツール、Concourseとは?
  • Spark 2.0の性能検証の結果とボトルネックの考察

    はじめに 前回は、Spark 2.0の主な変更点としてSpark 1.6よりも性能が向上し、アプリケーションの実装が容易になったことを解説しました。また、その性能検証のシナリオとして、電力消費量データを集計し可視化するケースを想定することを解説しました。今回は、シナリオに基づいた検証を行うための環境(システム構成、パラメータ)とその検証結果を解説します。 システム構成 データ分析システムの概要 データ分析システムは、図1のように管理画面とデータ分析アプリケーション、データ処理基盤の3つから成ります。設備企画担当者は管理画面を介してドリルダウン分析を行います。予めデータ分析アプリケーションで設備の負荷を集計し、その演算処理を実行するのがデータ処理基盤です。連載で取り上げるデータ処理基盤にはHadoopおよびSparkを導入しています。 ハードウェア構成 データ処理基盤は仮想サーバ3台、物理

    Spark 2.0の性能検証の結果とボトルネックの考察
  • 開発チームの環境をAnsibleで一括構築しよう

    連載ではこれまで、Ansibleの使い方から実際にPlaybookを書く際に役立つTips、テストの考え方などをご紹介してきました。最終回となる今回は、サンプルのPlaybookを使って開発チームのための環境を構築してみたいと思います。今回利用するPlaybookはこちらです。 https://github.com/OSSConsCloud/ansible_wg Playbookの紹介 今回利用するPlaybookは、連載の第2回から第7回までの著者らが参加しているOSSコンソーシアム クラウド部会の活動で作成したものです。MITライセンスで公開していますので、どなたでも自由に利用することができます。 このPlaybookでは、以下のOSSツールの環境構築を行うことが可能です。 GitLab (バージョン管理ツール) Jenkins (CIツール) Redmine (プロジェクト管理ツ

    開発チームの環境をAnsibleで一括構築しよう
  • Kafka、Spark、Elasticsearchのパラメータチューニング

    はじめに 第2回では、Spark Streamingを中心としたリアルタイムなセンサデータ処理システムの構築方法と、性能検証の進め方、および初期設定における性能測定結果を解説しました。 今回はシステムを構成するメッセージキュー「Kafka」、ストリームデータ処理エンジン「Spark Streaming」、検索エンジン「Elasticsearch」のチューニング方法と、チューニング後の性能測定結果について解説します。 前回のおさらい:初期設定における測定結果 初期設定で測定した結果、Kafkaの格納性能は8,026メッセージ/秒、Sparkの処理性能は19,346メッセージ/秒となりました。Kafkaがボトルネックとなり、システム全体のリアルタイム処理は8,026メッセージ/秒となります(図1)。この結果から、初期設定では第2回で解説した目標性能である10,000メッセージ/秒の処理性能を満

    Kafka、Spark、Elasticsearchのパラメータチューニング
  • 事例から考えるDockerの本番利用に必要なこと

    Dockerを取り巻く最新の状況 2016年4月13日にDocker 1.11がリリースされた。PaaS基盤としてのDockerをより便利に利用するために、ネットワークの機能やセキュリティ対策や構成管理ツールの機能が強化されている。さらに2月24日には、クラウドプラットフォーム上でコンテナの統合管理を行うDocker Datacenterもリリースされている。 さらにDocker社は豊富な資金力により、SDN(Software Defined Networking)企業であるSocketPlane社や、ハイパーバイザ型でDockerコマンドとの連携を実現している軽量OSを開発したUnikernel Systems社、DockerコンテナをパブリッククラウドにデプロイするSaaSサービスを提供するtutum社など、多数の企業を買収している。Docker社は各社の製品を統合し、PaaSプラット

    事例から考えるDockerの本番利用に必要なこと
  • アルパインがSparkでカーナビデータ分析の実証実験。RDBよりも数十倍の性能と多くの知見を獲得

    アルパインとクリエーションラインはSparkを使ったビッグデータ分析の実証実験を完了した。プロジェクトに関わった2人のキーパーソンに聞いた。 カーナビやカービジュアル製品を提供するアルパインは、近年ビッグデータ解析のオープンソースプロジェクトとして注目を集める「Apache Spark」を活用したビッグデータ分析の実証実験を、クリエーションラインと協業で行なった。 今回、この実証実験プロジェクトに参加したアルパインの黒田倫太郎氏と、Sparkのエンジニアとしてクリエーションラインから参加した木内満歳氏にインタビューを行った。 ―― 今回のプロジェクトはアルパインさんから木内さんに直接コンタクトがあったということですが、そのきっかけを教えてください。 木内:アルパインの研究部門でエンジニアをしていた黒田さんがクリエーションラインのグラフデータベースに関するブログ記事を読んでいて、あるセミナー

    アルパインがSparkでカーナビデータ分析の実証実験。RDBよりも数十倍の性能と多くの知見を獲得
  • OpenStack with OpenDaylight (手動構築編)

    前回はDevStackを使ってOpenDaylight(以降、ODLと省略)やOpenStackの構築を行った上で、連携の仕組みや簡単な使い方について触れました。DevStackという自動構築ツールを使ったので簡単だったと思います。 そこで今回は、DevStackによる構築はOpenStackにとどめ、ODLの手動構築にチャレンジしてみます。 環境・バージョンについて ノード構成やネットワーク構成などは前回と同じ環境ですが、ODLの構築はDevStackの管理外となります。ODLのバージョンは前回はDevStackのデフォルトである「0.3.5-SNAPSHOT」を使用しましたが、今回はLithiumのリリースである版「0.3.4-Lithium-SR4」を使うことにします。ODLとOpenStack連携の動作に違いはありません。 構築してみよう 全ノード共通の設定 それでは早速構築を始め

    OpenStack with OpenDaylight (手動構築編)
  • OpenStack with OpenDaylight(DevStack編)

    今回は、DevStack(http://docs.openstack.org/developer/devstack/)というツールを使ってOpenDaylight(以降、ODLと省略)とOpenStackを連携させた環境の構築にチャレンジしてみたいと思います。 それではさっそく構築方法について説明していきたいのですが、いきなり「ODLとOpenStackをそれぞれマニュアルに沿って構築して連携させてみましょう!」、というのは少し難易度が高いです。というのも、ODLは比較的新しめのOSSであるために情報が雑多で探しづらく、日語の情報も少ないというのが現状だからです。 そこで今回は、もっとも簡単とされるDevStackを使った構築方法をご紹介していきます。DevStackはOpenStack開発者達の間では、公式のテスト環境構築ツールとして親しまれています。数十行の設定ファイルを書いてスクリ

    OpenStack with OpenDaylight(DevStack編)
  • OpenStackの品質を保つ仕組みとは?:QA/Infraプロジェクトの最新動向

    OpenStack開発コミュニティには、投稿されたパッチを自動的にテストし、そのパッチが悪影響を与えていないことを確認する仕組み「ゲートテスト」があります。QAプロジェクトとInfraプロジェクトが連携してこのゲートテストを実装、実行しています。 QA(Quality Assurance=品質保証)プロジェクトには Tempest: 統合テストを実装する Grenade: アップグレードテスト(古い設定ファイルが使えるか、などをテスト)を実装する Devstack: 開発、テスト用OpenStackクラウドをデプロイする のコンポーネントがあり、ゲートテストではDevstackでデプロイしたクラウド環境に対して、TempestとGrenadeを実行することで投稿されたパッチの妥当性をテストすることにより、品質を確保しています。 またInfraプロジェクトでは、投稿されたパッチによってどのよ

    OpenStackの品質を保つ仕組みとは?:QA/Infraプロジェクトの最新動向
  • ベアメタル環境とDockerコンテナ環境の性能比較

    コンテナ環境とベアメタル環境の差異 前回は、Docker向け軽量Linux OSの主要3製品の比較を行った。Dockerを利用した環境の構築は、構築済みコンテナなどの利用により、比較的容易に行える。これは便利ではあるが、一方でコンテナ型仮想化環境には既存のベアメタル環境との差異がある。 コンテナ型の仮想化は軽量でリソース消費量が少ないが、コンテナ型仮想化環境にも管理レイヤは存在し、その上でコンテナが稼働している以上、どうしてもベアメタル環境に比べて性能劣化が発生することが予測される(図1)。 今回は、同一スペックおよび同一プロダクトを利用し、構築したDocker環境とベアメタル環境上で負荷テストを実施することで、両者の性能差を比較検証する。処理性能やリソース負荷状況などの観点で比較し、その差異を表やグラフにまとめているので、ご一読いただきたい。 まずは環境をご紹介する。今回は、図2のような

    ベアメタル環境とDockerコンテナ環境の性能比較
  • Docker向けの軽量Linux OS 主要3種を比較する

    Dockerをより効率的に利用するための技術 通常Dockerを利用する場合は、Linux OSが稼働するサーバ上にDockerのパッケージを追加でインストールすることで、環境を構築している。当然ではあるが、Linux OSのインストール時に「最小限の構成」を選んだとしても、Dockerの稼働には必要のないパッケージもインストールされている状態となる。 Dockerを利用する最大のメリットは、「少ないリソースでたくさんのコンテナ(=実行環境)を起動させられる」ことである。たとえ最小限の構成であってもDocker実行環境としては、多くのリソースが無駄に消費されていることとなる。さらに不要なサービスが実行されていることにより、Dockerで利用しない機能に対してもセキュリティー上のリスクが残ってしまうことになり、不要な運用作業が発生することとなる。 そのため、Dockerに対してもハイパー

    Docker向けの軽量Linux OS 主要3種を比較する
  • コード化でDevOpsを支えるHashiCorpのツールと開発背景

    HashiCorpとは? 「HashiCorp」という名前を知らなくても、Vagrantというツールの名前なら聞いたことがある、もしくはすでにお使いの方もいらっしゃるのではないでしょうか。Vagrantは仮想化された開発環境を簡単に立ちあげられるため、開発者サイドにとってはおなじみのツールです。このVagrantを開発したMitchell Hashimoto氏が創業した会社の名前がHashiCorpです。 HashiCorpが提供するツールは、開発者向けのものだけでなく、運用担当者向けのものもあります。連載初回の今回は、HashiCorpとは何であり、どのようなツールを、どのような考えで提供しているのかを紹介します。 HashiCorpの沿革 きっかけはVagrantの開発がスタート地点でした。Mitchell Hashimoto氏が2010年にVagrantバージョン0.1をリリースした

    コード化でDevOpsを支えるHashiCorpのツールと開発背景
  • Dockerの管理・監視ツール(2)

    前回は、シンプルなユーザーインターフェースのDockerUIと多彩な機能を備えたShipyardを紹介しました。今回は、エンタープライズでの利用を見据え、最近の注目株である、Rancher とDockerコンテナ同士のリンクをリアルタイムで可視化するWeave Scopeというツールを紹介します。 最近注目を浴びているDocker管理ツール「Rancher」 Rancherは、エンタープライズレベルでの運用を視野に入れたDockerの管理ソフトウェアです。LDAPGitHubによるユーザー認証、計算資源の使用状況の可視化、ログ出力、そして、クラウド環境やネットワーク上のDocker環境を跨いだ一元的な管理が可能となっており、注目が集まっています。2015年9月中旬現在、Rancherは、Amazon EC2、DigitalOcean、Rackspaceなどのパブリッククラウド上のDock

    Dockerの管理・監視ツール(2)
  • syslogを押さえよう!

    ログの出力方法 「第1回:必読!ログファイルとディレクトリ」では、CentOS 5.2の/var/logディレクトリ以下に存在する、ログファイルとディレクトリについて説明しました。第2回は、このさまざまなログファイルの管理について説明します。 ログの出力方法という観点からみた場合、ログは、アプリケーションが独自の方法で出力したものと、Unix/Linuxにおける標準的なログ出力方法であるsyslogを利用して出力されたものとに大別できます。 アプリケーション独自の方法で記録されたログファイルとしては、/var/log/wtmpや/var/log/lastlogといったバイナリ形式のファイルがあります。また、ApacheやSamba、Squidなど、独自のログディレクトリを持つアプリケーションの多くも、独自の方法でログを記録しています。 一方、syslog は、独自のログ出力方法を持たない、

  • Dockerの導入前に知っておくべきこと

    IT部門は、現在よりも柔軟性の高い効率的なITシステムにするために、開発部門と協調し、自社のシステムにDockerを採用すべきかどうかの妥当な判断をしなければなりません。このDockerの採用可否に関する「妥当は判断」は、短時間で結論が出るものではありません。ベンダーや自社の有識者が集い、導入目的、採用可否、設計指針などをある程度具体的に検討しなければなりません。章では、Dockerの導入を検討する場合に知っておくべき前提知識、検討項目を述べます。さらに、実際にDockerを導入時する際に知っておくべき項目を述べ、最後に、導入手順と注意点について述べます。 Docker導入前の検討事項 Dockerを導入する上で、検討しなければならない項目としては、まず、「そもそもDockerが自社に必要なのか?」ということです。Dockerは、コンテナを管理するためのソフトウェアであり、非常に優れた機

    Dockerの導入前に知っておくべきこと
  • 自動化・省力化のためのSerf入門

    Serfが必要とされる理由 複数のサーバ環境上で、一斉にセットアップ用やデプロイ用のコマンドを実行したり、バージョン番号の確認を行ったりするためには、どのような方法が最適でしょうか。管理対象が数台程度であれば、毎回手打ちでSSHログインを実行し、コマンドを実行する方法もありでしょう。 しかし、その作業が同じ手順の繰り返しである場合や、システムにおける作業対象が十数台~数百台まで増えたとしたらどうでしょう? 人の手で行うとなると、作業にかかる時間が増える上に、作業ミス発生のリスクも高まります。ミスを防ぐためには、チェックの仕組みも必要となります。たとえそれが単純な作業だったとしても、システム全体としては非常に面倒なものになりがちです。 このような問題を解決するためのツールとして、parallel-sshが挙げられます。parallel-sshは名称の通り、ある環境上から対象となるサーバ群に対

    自動化・省力化のためのSerf入門
  • Dockerを理解するための8つの軸

    Docker」というキーワードが、サーバーまわりのキーワードとして定着しつつある。その一方で、触ったことのある人以外からは、「Dockerってよくわからない」「コンテナーって昔からあるのでは?」という声も聞く。 Dockerは、それまでにあった要素技術を組み合わせることで、サーバーアプリケーションを実行する便利な方法を作り出したものだ。そのため、1つの要素技術を見ただけでは、新しさや全体像がわかりにくい。 そこでこの記事では、Dockerを触ったことのない人向けに、Dockerを8つの軸から説明する。なお、ここではDockerそのものを解説するわけではないので、ご了解願いたい。 1. コンテナー Dockerはまず、コンテナー管理ツールだ。 コンテナーとは、1つのサーバーの上で、複数のサーバー環境をそれぞれ分離して実行する、一種の仮想化技術だ。「OSレベルの仮想化」とも呼ばれる。 複数の

    Dockerを理解するための8つの軸
  • 検索

  • NOSQLの新顔、分散KVS「okuyama」の機能

    NOSQLについて解説した前回の記事は、いかがだったでしょうか。今後のアプリケーションでは、増え続けるデータを扱うことが非常に多くなると思います。前回の記事が、こうしたケースに適した新たなストレージの1つとして、NOSQLを理解するきっかけになっていたら幸いです。 連載2回目の今回は、NOSQLの1つである「okuyama」の全体概要と、機能的な特徴を紹介します。 1. 「okuyama」の概要 okuyamaは、まだ聞きなれない方も多いかと思いますが、筆者が開発している分散キー・バリュー・ストアです。2009年12月ごろから開発を始めました。現在はSourceforge.jpにて公開しています。もともとは学習を兼ねて作成したため、一部のログ・ライブラリなどを除き、すべて1から実装しました。2010年1月にファースト・リリースを行い、現在はバージョン0.8.6となっています。 以降は、ok