Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード

2018-07-16

「コスパのいいシステムの作り方」の紹介

三菱UFJインフォメーションテクノロジーの南さんから献本いただきました。南さんとは一緒に仕事をさせていただいたこともありますが、難易度の高いミッションクリティカルプロジェクトを成功させられていて、こういうベンダーに騙されない目利きができる優秀なPMはユーザー企業の宝だと思っていました。

南さんのようなユーザー企業でリスペクトしている方々に共通しているのは会社のお財布は自分のお財布という感覚を持ち、各分野のスペシャリストと個人的なコネクションを持たれ、ドライな技術からウエットな組織まで筋の通った骨太な考え方を持たれて、馬力があって肝が座られてるところです。ちょっとマネできないなと感じます。

こういうスキルはなかなか人に伝えることは難しいと思いますが、本書はそれを可能な限り搾り出した一冊だと思います。自分がユーザー企業に転職することがあれば、本書を参考にさせていただきたいと思います。

著者が経験を通じて得た経験と勘(暗黙知)を脳内バッファから書出したような一冊です。

システムの「コストパフォーマンス(費用対効果)」に限らずインフラの要素技術、勉強の仕方、後輩の育て方、組織についてなど経験から得られた暗黙知が簡潔に書かれています。

日本のIT業界は内製せずにSIerに委託しているユーザー企業が多いですが、その場合、プロジェクトの成否は製品やソリューションの選定、ベンダーコントロールなどユーザー企業のプロジェクト担当の目利きや腕にかかっていると感じます。

よく、この人はこの会社にいてもらわないとと思うことがあります。

本書はユーザー企業のインフラエンジニアはもちろん、そこに提案に行くベンダーも役に立つと思います。以下、構成と目次です。


概要

「うちって,システムにお金をかけすぎじゃない?」

そんな問いに的確な判断を下すにはどうすればいいか。

「勘に頼らない技術を求めても,結局は勘に頼る部分が少なからずある」

「過去の事例と比較しても,元のコストがまちがっていれば誤りの連続になるし,すぐに陳腐化する」

そんなジレンマに悩む方のために,大規模システムを多数経験してきた著者が,最小限のコストで最大の効果を得る「勘と経験」の本質を教えます。

コスパのいいシステムの作り方 ?しっかり見積もりたいのに勘を使うジレンマに向き合う:書籍案内|技術評論社

構成

本書では,テーマごとに私の経験と勘を明らかにしていこうと思いますが,以下のスキルが重要になります。

これらのスキルを,本書では3部構成でまとめています。まず第1章から第8章までは,システムを構築するうえでの前提知識をまとめました。システム構築は単に技術力があればできるものではありません。幅広い知識と経験が必要で,その要素をまとめています。続いて第9章から第12章まではインフラのテクニカル要素をレイヤーごとに記載しています。何か1つの製品については触れず,どのような製品を使っても役に立つ考え方を記載しています。最後に第13章は,それ以前の章の総まとめです。実際のシステムのパターンごとに,第12章までの知識を集約して考え方を整理しています。

これらのスキルは私のこれまでの経験によるものですが,どのように考えてきたかをお伝えすることで,みなさんの経験と勘にプラスできることを願っています。


目次

出版社の紹介は コスパのいいシステムの作り方 ?しっかり見積もりたいのに勘を使うジレンマに向き合う:書籍案内|技術評論社 をご覧ください。

第1章 どうやって予算を確保するか
文化の違いで変わる見積りへの影響
プロジェクトごとの予算確保から案件化まで
予算が決まった後にすべきこと

第2章 製品を安く買うための工夫
「製品は安く、工数はほどほどに」がコツ
製品の強み、弱みを正確に把握する
ダブルスタンダードで価格をコントロールする
購入時に確認すべき3つのこと

第3章 開発費を削減するための工夫
インフラのコストを下げる基本原則
内製化を検討する
契約で考えるべき4つのポイント

第4章 可用性、性能、運用性を考慮する
システムのコストとSLA
可用性について考察する
性能について考察する
運用性について考察する
後から変わるSLAで不幸にならないためにすべきこと
後々SLAでもめないためのインフラのポイント

第5章 OSSかプロプライエタリか
バグの対処の方法によってコストは大きく変わる
OSSの強みとは
OSSの向き不向きを考える

第6章 標準化でコストダウンは図れるのか
標準化の功罪とは
コスト効率と安全性を追求する標準化の進め方

第7章 運用・保守の効率化を考える
増えていくシステム、減らしにくいランニングコスト
保守作業を合理化するための考え方
運用フェーズのコスト削減のポイント
開発・運用の分離とDevOps

第8章 教育コストと体制維持コストの負担
エンジニアが成長するための4つの基本
技術スキルの伸ばし方
教育のためのコストを捻出する

第9章 サーバー(IaaS)のコストを考える
「速いか遅いか」「壊れにくいか壊れやすいか」の2軸でコストを考える
CPUの費用対効果
メモリの強みを理解する
ディスクの故障とシステム停止を想定する
ラックマウントサーバーか、ブレードサーバーか

第10章 仮想化でリソースを効率的に扱う
見積もりとコントロールがうまくできないから仮想化が必要になる
リソースをリニアに追加・削除するときの注意点
集約率を高め、効果的に仮想化するには

第11章 ストレージを効率的に使い切る
ブロックストレージの投資対コスト
思ったよりも使えないディスク容量
ディスクの特性と価格変動を考える
ブロックストレージ以外のストレージを使いこなす

第12章 ミドルウェアがコストに与える影響を理解する
ライセンスコストが問題になりにくいAPサーバー
高額でプロプライエタリなRDBMS製品を使う理由
RDBMSで無駄なリソースを使う問題をどう解決するか
NoSQLの活用でコストは減らせるか
アプライアンス製品か、汎用品か

第13章 システムタイプごとの高コスト、低コスト
シンプルなAP、DBの構成
同時実行ユーザーが多いシステム
ミッションクリティカル系
スパコン・HPCの場合

2018-07-07

コンテナ について

コンテナという言葉の意味

container

con-「共に」tain「つかんで離さない」-er「人、もの」

->何かをとどめようとするもの

-> 【名】入れもの、コンテナ

英単語 container の語源と意味 - Gogengo! - 英単語は語源でたのしく

コンテナ (英: container)とは、内部に物を納めるための容器のことである。コンテナーとも呼ばれる。

コンテナ - Wikipedia

コンピュータにおけるコンテナ

 商用OSの世界でも、SolarisゾーンやHP-UX Containersなどのように、コンピュータ資源を分離する「コンテナ技術」が発展していきました。ここで、コンテナという言葉が出てきます。コンテナとは船や列車などの貨物輸送で使われる容器です。一隻に大量のコンテナを積載して運ぶ貨物輸送船を思い浮かべて下さい。

 なぜ貨物でコンテナが利用されるのでしょう。容器を直方体の箱にすれば船の限られたスペースにすき間なく積み上げて効率よく配置でき、異なる種類のコンテナ同士で内容物が混ざるといったトラブルも避けられます。依頼主にも管理側にもメリットがあるからです。

 この「隙間なく積み上げて配置できること」と「内容物が混ざるトラブルが発生しないこと」という点が非常に重要です。コンピュータにおけるコンテナも同じ考え方です。コンピュータにおいて、一隻のコンテナ船はホストOSです。その上に載る大量のコンテナの群れには、それぞれさまざまなアプリプロセスが稼働しています。隙間なく積まれたコンテナの群れをよく目を凝らしてみてみると、コンテナ同士はぴったりとくっついて配置されていますが、お互いのコンテナは、となりのコンテナの内容物(プロセス)は知り得ません。すなわち、ホストOSであるコンテナ船から見た人は、コンテナという分離された空間がいくつも存在するかのように見えます。これが、分離された空間=コンテナと呼ばれるゆえんです。

 また、船の平らな甲板にコンテナが直接触れて置かれている点も重要です。平らであるということをコンピュータに置き換えると、ホストOSとコンテナが直接触れているということは、ホストOSとコンテナの間にはハイパーバイザーのような介在者がいないことになります。すなわち、コンテナで稼働するアプリプロセスは、ホストOSから直接起動されているのです。

第4回 「Dockerのクジラロゴ」が意味するもの (2/3) - ITmedia エンタープライズ

他の仮想化とコンテナの違い


コンテナの歴史

f:id:yohei-a:20180708124417p:image:w640

chroot が生まれた背景

 一般的にアプリなどの稼働テストにおいて、実際の本番環境のファイルなどを直接作成、変更、削除するのは、非常に危険です。chroot監獄は、このような本番環境で試すと危険をともなう場合と比べ、ソフトウェアの開発やテスト環境を安全に行うことができます。当時は非力な計算機を使って、BSDなどのUNIX向けにさまざまなソフトウェアの開発が研究機関において行われていました。このような「監獄」の考え方が出現したのは、ソフトウェア開発者が1台のマシンで本番環境をシミュレートして、効率的にかつ安定的に開発を行いたいというニーズが背景にあったためです。

f:id:yohei-a:20180708124941j:image

本番機と開発機を2重に持たず、本番機で開発するのは非常に危険。そこで、本番用のファイルシステムの一部を分離(隔離)するという考えが生まれた

第1回 Dockerと「昭和54年」の深〜い関係 - ITmedia エンタープライズ
chroot の応用例

chroot監獄は開発の場面だけでなく、システムファイルの破損や、操作ミスなどで誤ってファイルを削除してしまい、OSが起動不能になった場合に、インストールメディアレスキューモードを使ってOSを復旧させるシーンにおいても使われています。

 具体的には、インストールメディアで対象となるマシンを起動後、破損したOSのルートディレクトリを適当な名前のディレクトリ(/mnt/sysimageなど)にマウントすることに成功すれば、そのディレクトリchrootを実行することで、破損したOSのルートディレクトリに遷移できます。これにより、起動不能だったOSのコマンド群を使えるようになり、復旧作業を行うことができます。

 また、セキュリティの面においても「ハニーポット(蜜の壺/おとりサーバ)」と呼ぶクラッカー対策にchrootが利用されます。現在(2015年)では、chrootを使ったハニーポットに代わる新しいセキュリティ対策の仕組みがいろいろと研究されていますが、基本的にはchrootの考え方を踏襲しており、2015年現在でもフリーOSなどで利用されています。

f:id:yohei-a:20180708125240j:image

chrootの応用例。chrootファイルシステムの分離機能はソフトウェアの開発だけでなく、さまざまな分野で応用されている

第1回 Dockerと「昭和54年」の深〜い関係 - ITmedia エンタープライズ
FreeBSD Jail

2000年、オープンソース界隈であるホットなニュースが飛び交いました。

 chroot監獄を大幅に発展させた機能が、フリーOSで利用可能となったのです。その名も「FreeBSD Jail(フリー・ビーエスディ・ジェイル)」です。「あるディレクトリ配下をルートディレクトリに見せる」というファイルシステムを取り扱う概念に加え、さらにアプリプロセスIDも監獄ごとに分離できるようになりました。

 このFreeBSD Jailは、監獄の中からホストOS側を見ると、ホストOSの各種資源の一部分だけがあたかもすべての資源のように見せることができる画期的なものです。FreeBSD Jailはとても軽く、洗練されたアーキテクチャとして知られており、日本やロシアで根強い人気があるFreeBSDと呼ばれるBSD系のフリーOSにおける強力なOS空間の分離機能として発展し、2015年現在でも広く利用されています。

 その後FreeBSD Jailは、VIMAGEと呼ぶネットワークに関する分離機能も追加されました。

第4回 「Dockerのクジラロゴ」が意味するもの (1/3) - ITmedia エンタープライズ
Dockerが生まれた背景

Googleでのコンテナ

つまり私たちが利用するGoogleのすべてのサービスも、Googleの社内で使われているツールもすべて、すでにGoogleではDockerのようなコンテナ型仮想化技術の上で実行されているということのようです。

「We start over 2billion containers per week.」(私たちは毎週20億個以上のコンテナを起動している)とも書いてあり、Google内部ではすさまじい数のコンテナが実稼働していることになります。

いまDockerを中心にコンテナ型仮想化が話題になっていますが、Googleではすでにコンテナがあたりまえの技術になっている、ということなのでしょう。

no title

Fargate

f:id:yohei-a:20180708132118p:image:w640

f:id:yohei-a:20180708132124p:image:w640

f:id:yohei-a:20180708132112p:image:w640


Kubernetes

Kubernetesとは

Kubernetesオープンソースの「コンテナオーケストレーションツールです。公式サイトのトップページにおいてもそう明示されていますが、「コンテナオーケストレーション」には明確な定義がまだありません。そこで本連載では、コンテナオーケストレーションを「コンテナ型仮想化を本番環境で活用するために必要な機能を提供すること」と定義します。

(中略)

Kubernetesの起源

Kubernetesの起源をたどる際には、Googleエンジニアが執筆したサービス管理に関する有名な論文が参考になります。この論文では、「Googleのサービスは、クラスタマネジャー『Borg』上で動作するコンテナを用いて提供されており、Borgと同様の仕組み(+Borgにおける反省を踏まえた対応策)を備えたオープンソースソフトウェアとしてKubernetesを開発した」旨が記載されています。

Googleのサービスを支えている基盤と同様の仕組みを備えていることから、「KubernetesGoogleで既にその有効性を実証済みである」という意味で大きな注目を浴びたといえるでしょう。

「Kubernetes」とは何か――コンテナ型仮想化の本番利用に向けた課題:先行事例に学ぶKubernetes企業活用の現実(1) - @IT

Kubernetesは要するに、プロセッシングのリソース管理の問題などを解決するためのオーケストレーションソフトウェアです。

プロセッシングだとか、ハイアベイラビリティだとかを。Kubernetesと、あとKubernetesが動作の前提とするEtcdという分散キーバリューストアをペアにして解決していくというものになりますが。

no title

EKS


参考

  • コンテナの性能分析

2011年7月1日

米国の新興クラウドベンダである「DotCloud」が、ベータ期間を終了し、正式サービスを開始しました。

DotCloudの最大の特徴は、PHPPerlRubyJavaPythonNode.jsなど複数の言語と、MySQLPostgreSQL、Cassandra、MongoDBCouchDB、Redisなど複数のデータベースMemcached、RabbitMQ、Hadoopなどのさまざまなソフトウェアを開発者が自由に組み合わせてプラットフォームを構成することができ、それがクラウド上のPaaSとして提供されるという点です。

(中略)

シックスアパート宮川達彦氏が、4月にDotCloudへ転職したことブログで明らかにしていますが、そのエントリで宮川氏はこのように書いています。

I hope to see Perl deployments beat Ruby and Node.js on DotCloud some day :)

クラウド上の言語としてPerlが使えるプラットフォームはこれまでほとんどありませんでした。果たして、新しい世代のPaaSではどのような言語やデータベースが主流となるのでしょうか?

プログラミング言語やデータベースが選べる新世代PaaS「DotCloud」が正式サービス開始

1番のポイントは、PDBがいくつあってもインスタンスは1つだけというところです。PDBごとにメモリやプロセスを割り当てていたのでは、従来型のデータベースを複数作成する場合と同じで無駄なリソースを多く使用してしまいます。インスタンスを各PDBが共同利用することで、リソースを節約しようというのがOracle Multitenantの考え方なのです。こうして集約率を高め、さらにPDBとして独立性を持たせることで、スキーマ名の競合やセキュリティ見直しといった統合にありがちな課題まで、まとめて解決することができます。

徹底解説!Oracle Database 12cのすべて Vol.1 | アシスト

Webコンテナ(ウェブコンテナ、Web container)とは、Java Platform, Enterprise Edition (Java EE) アーキテクチャのWebコンポーネント規約を実装するソフトウェア[1]。Java Servletの実行環境となることからServletコンテナ(サーブレットコンテナ、Servlet container)とも呼ばれる。

この規約では、コンピュータセキュリティ、並列性、ライフサイクル管理、トランザクション処理、デプロイやその他のサービスを含むWebコンポーネントの実行環境を規定している。WebコンテナはJava EEプラットフォームAPIを利用したJSPコンテナとしての機能も提供する。

Webコンテナ - Wikipedia

データプレーン、コントロールプレーン

Docker container networking:overlay networkで出て来る。

Dockerのネットワークを理解するためのネットワーク技術入門 – PAYFORWARD

Docker EE networking features

The following two features are only possible when using Docker EE and managing your Docker services using Universal Control Plane (UCP):

Docker container networking:overlay network

上のスライドの黒塗り箇所が YouTube では見れる

2018-04-08

Netflix のオープンソース可視化ツール FlameScope を使ってみた

Brendan Gregg らの所属する Netflix の cloud performance engineering team が FlameScope というパフォーマンス可視化ツールオープンソースで公開した。詳しくは Netflix Tech Blog 参照。

flame graphs は瞬間的なスパイクを分析しづらかったが、FlameScope により1秒未満のヒートマップでイベント発生回数の多い時間帯が可視化されピンポイントで特定期間の flame graph を表示できるようになった。Oracle Database でいうと AWR/Statspack レポートだけでなく ASH 的な分析、さらに1秒未満のCPU時間の内訳のプロファイリングまで Craig Shallahamer の fulltime.sh でズームアップできるイメージ*1

FlameScope は Pyhton(フレームワークは Flask) で書かれた Web アプリで、Perf で取得したデータを、ブラウザでアクセスして flame graph を分析するツールです。


Brendan Gregg は性能分析の大家でバックグラウンドは以下の通り。

Flame Graphs の作者の Brendan Gregg は Sun、Oracle、Joyent でカーネル、パフォーマンスのエンジニアとして活躍し、現在は Netflix(北米のインターネットのトラフィックの32.3%を占める。YouTubeは17.1%)*2 のシニア・パフォーマンス・アーキテクトです。ZFS L2ARC や DTrace Toolkit の開発者で、Solaris Performance and ToolsDTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD の著者で、LinuxConFreeBSD SummitOaktable WorldAWS re:Invent などのイベントで幅広く活動されています。是非 Brendan Gregg’s Homepage をご覧ください。

perf + Flame Graphs で Linux カーネル内のボトルネックを特定する - ablog

FlameScope の見方

x軸が秒単位、y軸が1秒未満の時系列になっていて、赤いセルほどイベント発生回数が多い(CPU負荷が高い)。密度を高めるため2次元にしていると思われる。

f:id:yohei-a:20180408180622p:image:w360

実際のスクリーンショットはこんな感じで、x軸が秒単位、y軸が1秒未満の単位になっていて、

f:id:yohei-a:20180408180626p:image:w360

選択範囲の FlameGraph を表示することができる。

f:id:yohei-a:20180408180632p:image:w360

flame graph の見方は以下の通り。詳しくはこちら

  • 関数名で左から右にソートされている
  • コールスタックは上に行くほど深い
  • 最もコールスタックが深くて横幅が長いのがCPUを最も使っている関数

FlameScope を使ってみる

macOS に FlameScope をインストールして、Linux で perf で取得した性能情報をダウンロードして、FlameScope で可視化してみた。

f:id:yohei-a:20180408230316p:image:w360 f:id:yohei-a:20180408230323p:image:w360 f:id:yohei-a:20180408230329p:image:w360


環境
  • 性能情報取得環境
  • FlameScope実行環境
    • macOS Sierra 10.12.6

インストール
$ sudo yum -y install perf
$ git clone https://github.com/Netflix/flamescope
$ cd flamescope
$ sudo pip install -r requirements.txt

使ってみる
  • EC2 で perf で性能情報を取得しつつ openssl で負荷をかける
    • perf で性能情報を収集する
$ sudo perf record -F 49 -a -g -- sleep 120
$ sudo perf script --header > stacks.openssl.2018-04-07_01
$ gzip stacks.openssl.2018-04-07_01
$ ls -lh stacks.openssl.2018-04-07_01.gz
-rw-rw-r-- 1 ec2-user ec2-user 389K Apr  8 13:45 stacks.openssl.2018-04-07_01.gz
$ openssl speed -multi 4
  • macOS で FlameScope を起動する。
    • FlameScope を起動する
$ python run.py
    • flamescope/examples 以下に EC2 から stacks.openssl.2018-04-07_01.gz をコピーする。
    • ブラウザで http://127.0.0.1:5000/ にアクセスする。

スタックのリストが表示されるので、stacks.openssl.2018-04-07_01.gz をクリックする。

f:id:yohei-a:20180408230316p:image:w640

ヒートマップを表示すると綺麗に2分間計測したうち1分経過後から30秒間が赤くなっている。

f:id:yohei-a:20180408230323p:image:w640

範囲を選択してクリックすると flame graph を見ることができる。

f:id:yohei-a:20180408230329p:image:w640


参考


関連

*1:細かすぎて伝わらない例えかもしれない。。。

*2http://wazanova.jp/post/62392993571/30-netflix-amzazon

2018-03-31

「Oracleの基本 〜データベース入門から設計/運用の初歩まで」の紹介

株式会社コーソルの 渡部さんOracle ACE)から献本いただいた「Oracleの基本 〜データベース入門から設計/運用の初歩まで」の紹介です。

一言で言うと新卒研修でデータベースの教科書として最適な本だと思います。

渡部さんとは JPOUG などのコミュニティ活動で以前から交流があり、コーソル社の社内勉強会にも何度かお邪魔したこともあります。Oracle 関連のイベントにお手伝いに来られた新卒ホヤホヤの方と挨拶したと思ったら数年後には第一線の現場で一緒に仕事させていただいたりしていましたが、ITの知識がなかった新卒や中途入社の方が数年後には一流のDBエンジニアとして第一線の現場やイベントの発表などで活躍されていて、データベース*1を勉強するには最もよい会社の一つだと思っていました。そのコーソル社のエンジニア育成で培われたノウハウが詰まった一冊だと思います。

敢えてアーキテクチャの説明を必要最低限に抑えて、Oracle Database をインストールして使いながら一通りの機能を使いながらウォークスルーする構成になっていて、コーソル社の育成の現場で培われたノウハウが詰まっていることが感じとれます。

初心者が資格取得から始めると暗記科目のようになってしまい、業務で一通り触れてからとなると1年以上はかかってしまったりしますが、本書は初心者が Oracle Database を最初に学ぶ上での高速道路になると思います。

また、ただの機能説明だけではなく著者陣の経験から得られたハマりポイントやなぜそうするかが散りばめられており、初心者ではなくても気づきがあるのではないかと思います。



オススメの読み方

Oracle Database を使ったことがない初心者の方が手を動かしながら通読するのがオススメです。ORACLE MASTER 取得や DB エンジニアを目指されているか方もまずはこの本を Oracle Database を使いながら通読するのが一番の近道ではないかと思います。


対象読者


一部引用

  • はじめに(P.3-4)

そこで,本書はOracle独自の用語の使用を最小限にとどめ,次の2点を考えながら執筆しました。

  • 平易な表現を用いてOracleを解説すること
  • データベースOracle,開発,設計,運用の基本について広くさまざまな視点から学べること

これらの解説ノウハウは,弊社コーソルの新人教育で培われたものです。コーソルの新人教育には,約2週間という短い期間で多くの新卒エンジニアORACLE MASTER Bronze DBAに合格させているという実績があります。さらに最近では,IT 未経験の新人エンジニアが,入社から2年半で,ORACLE MASTER Platinum(2日間の実技試験により認定されるORACLE MASTERの最上位資格)を取得するような例も出てきています。本書には,コーソルの新人エンジニアの生の声を反映させ,ノウハウを惜しみなく注ぎ込みました。

Oracleの基本 ?データベース入門から設計/運用の初歩まで:書籍案内|技術評論社
  • おわりに(P.353)

入門書という位置づけから、本書では、機能や使用方法に重点をおいて説明しました。よって、アーキテクチャについての説明を割愛しているところがあります。しかし、ひととおり、 Oracle を使えるようになったら、アーキテクチャにも目を向けてみてください。エンジニアであれば、「ソフトウェアがどうやって動いているか」ということに興味を持つのは自然なことですし、なにより、アーキテクチャを知っているかどうかで、理解度やスキルの伸びに大きな差が出てきます。


目次

はじめに
本書について
第1章 データベースを知る
1.1 なぜデータベースは必要なのか
1.2 リレーショナルデータベースの基礎
本書の構成
第2章 Oracleを使ってみる
2.1 データベースを構築する
2.2 データベースに接続する
2.3 データベースを起動/停止する
2.4 学習用ユーザーを作成する
2.5 テーブルとデータ操作の基本
第3章 より高度なデータ操作を学ぶ
3.1 データを複雑な条件で検索する
3.2 データを加工/集計する
3.3 NULLとIS NULL条件
3.4 SELECT文とSELECT文を組み合わせる
3.5 テーブルを結合する
3.6 データの表示画面にこだわる
3.7 トランザクションでデータを安全に更新する
第4章 データをより高速に/安全に扱うしくみ
4.1 検索処理を高速化するインデックス
4.2 SELECT文をシンプルにまとめるビュー
4.3 不正なデータの混入を防ぐ制約
4.4 連番を振り出すシーケンス
4.5 セキュリティ機構の基礎となるユーザー機能
4.6 ユーザー権限を制御する
第5章 テーブル設計の基本を知る
5.1 テーブル設計とは
5.2 第1ステップ‐概念設計
5.3 第2ステップ‐論理設計
5.4 第3ステップ‐物理設計
第6章 データベース運用/管理のポイントを押さえる
6.1 データベースにおける運用/管理の重要性
6.2 バックアップを取ってデータを守る
6.3 データベースのメンテナンス
6.4 データベースを監視する
6.5 ネットワーク環境/本番環境でOracleに接続する
6.6 トラブルに立ち向かうためには
おわりに
索引
著者略歴
監修者略歴

*1データベースを勉強するなら Oracle Database から入るのがオススメです

2018-03-03

MySQL のバイナリログとInnoDB ログ

MySQLのバイナリログはメディアリカバリに使うもので、ディスク障害などの際に mysqldump でエクスポートしておいたデータをインポートしてバイナリログでロールフォーワードする。Oracle Database で言うと、 インポートがリストアで、バイナリログでのロールフォーワードがアーカイブログとREDOログを使ったロールフォーワードに当たる。Oracle Database が物理的なブロックレベルで行う宇野に対して、MySQL は論理的にSQLベースで行う点が異なる。

InnoDBログはインスタンスダウンした時にクラッシュリカバリでロールフォーワードに使われる(ロールバックにはUNDOログが使われる)。Oracle Database がREDOログでロールフォーワードしてUNDO表領域のロールバックセグメントでロールバックするのと同じ。


  • InnoDBログ

  • バイナリログ


バイナリログを使っている場合、--innodb_support_xa を 1 に設定していると、InnoDBログとバイナリログの一貫性が保証される。sync_binlog が 1 の場合、クラッシュリカバリ時にバイナリログを走査して truncate して、マスターでロールバックしたトランザクションはバイナリログから削除するようだ。これが残っていると、マスターでDMLは発行されたけどロールバックされたトランザクションがスレーブに連携されて永遠にコミットされないトランザクションになるからではないかと思う。

For example, if you are using InnoDB tables and the MySQL server processes a COMMIT statement, it writes many prepared transactions to the binary log in sequence, synchronizes the binary log, and then commits this transaction into InnoDB. If the server crashes between those two operations, the transaction is rolled back by InnoDB at restart but still exists in the binary log. Such an issue is resolved assuming --innodb_support_xa is set to 1, the default. Although this option is related to the support of XA transactions in InnoDB, it also ensures that the binary log and InnoDB data files are synchronized. For this option to provide a greater degree of safety, the MySQL server should also be configured to synchronize the binary log and the InnoDB logs to disk before committing the transaction. The InnoDB logs are synchronized by default, and sync_binlog=1 can be used to synchronize the binary log. The effect of this option is that at restart after a crash, after doing a rollback of transactions, the MySQL server scans the latest binary log file to collect transaction xid values and calculate the last valid position in the binary log file. The MySQL server then tells InnoDB to complete any prepared transactions that were successfully written to the to the binary log, and truncates the binary log to the last valid position. This ensures that the binary log reflects the exact data of InnoDB tables, and therefore the slave remains in synchrony with the master because it does not receive a statement which has been rolled back.

no title

参考

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

Webエンジニアのための データベース技術[実践]入門 (Software Design plus)

P.155

バックアップ間隔とリカバリにかかる時間


UPDATE文であればデータファイル自体のサイズには大きな影響がないことが多いので、リストアにかかる時間は大差ありません。したがって、復旧時間の差はこのUPDATE文の実行時間の差に近くなるでしょう。1ヶ月分のUPDATE文を実行するとなると、膨大な時間がかかる可能性があることに注意が必要です。バックアップの間隔を空け過ぎていたため、バイナリログを全部当て終わるのに2日かかった、という失敗事例もありました。


http://h50146.www5.hpe.com/products/software/oe/linux/summary/reference/pdfs/MySQL-backup.pdf