RDBMSの機能と活用について

自分は、とある場所で勉強会を月１回主催しています。毎回色々なテーマで勉強をするのですが、その中で思ったことがあります。

アーキテクチャの議論の中で、いわゆる３階層構造（データベース、アプリケーションサーバー、クライアント）の構成は、現在はあまりにもアプリケーションサーバーに処理が偏りすぎていて効率的ではないのではという議論がありました。

今自分が直面している課題は、

何十万件のレコードをデータベースからとってきて、金額を計算して、別のテーブルに書き込むという処理で、短時間の間にその処理を完了しなければならないという者です。

要件はたったそれだけなのですが、実現にはいくつかのやり方があります。

パターン１　データを一気にアプリケーションサーバーにもってきて、金額計算をして、テーブルに書き込む。
問題点：アプリケーションサーバーのメモリをものすごく食う。何十万回のINSERTが発生する。→アプリケーションサーバーでエラーが発生するかも。書き込みにものすごく時間がかかる。（もちろん高速化のテクニックはいくつかありますが）

パターン２　データをグルーピングして、塊ごとにLOOPさせて、金額計算をして、テーブルに書き込む。（１の派生系）
問題点：１よりはメモリを食わないが（それでも書き方によるが）、やはり書き込みに時間がかかる。（多重LOOPの中でSQLを発行するのは最悪）

パターン３　SQLで金額計算まで行い、テーブル間でデータをコピーする。
上記問題点は起きないが、ビジネスロジックがSQLに埋め込まれる。
（ストアドプロシージャだとデータベースの中にビジネスロジックが埋め込まれる）

パターン３は、明らかにトレンドに反するが、処理速度は段違いとなる。
机上の計算だと、何十倍も処理速度の差が出て来ることになる。

現在のトレンドだと、RDBMSは、入れ物であってロジックを実装することは、ほとんど無い。（トリガーや参照整合性制約や、チェック制約を実際に使うことは最近ほどんど見かけない）なので、アプリケーションサーバーの役割が増大してしまっている。
（一部バッチ処理にストアドプロシージャを使うことがあるが）

今日やった勉強会では、RDBMSでできることは、RDBMSでやったほうがいいのではという結論になった。（SQLを舐めすぎ！！）

また複雑なSQLに対する恐怖感があるのでは無いかということを感じた。最近のRDBMSは、サブクエリなんかなんとも無い。

それこそ、キーでもってデータを取り出すだけならNO SQLでいいのではと思う。

よって、今年の目標は、RDBMSを極めることとした。

2016年振り返りと2017年目標と予測

久しぶりにブログを書いてみる。12月は色々忙しく、書く気力がありませんでした。

2016年は、一旦自分の研鑽のために、今後10年のために、勉強に割り当てると決めたはずだった。しかしながら秋には変節し、再びプロジェクトへと参画した。参画自体は後悔はしていないが、時間の使い方を見直さなければなあと考えた。
最初はIT技術の全方位を勉強しようといろいろ読み漁り、自分のPCにインストールをし、勉強をした。しかし現在、IT技術はますます多様化、複雑化していて、全方位で勉強するにはとてつもない時間が必要と感じた。
2017年、プロジェクトがどうなるかはまだわからないが、プロジェクト内で本務ではないが、データベースのことを考える機会が多かった。もしもう少し勉強をする時間ができたらデータベース技術を中心に勉強してみたい。

さて世の中全般をみると、2016年は、AIの年だったと言えるかもしれない。将棋や囲碁が話題になったが、自分にとっては、AIの医療や自動運転への応用が驚いた。

人間では思いつかなかった治療方法がAIから提案されたり、
過去には、自動運転について懐疑的な内容のブログを書いたりしたが、いろいろ調べるにつれ、実はもうすでに人間が運転するより、AIが運転するほうがより安全なレベルまで進歩しているとか。

2017年もやはりAIの応用を中心に世の中は動いていくと思う。もっと言ってしまえば人間と世の中のサイバー化が進んでいくのではと考える。（パラリンピックで障碍者が、補助器具の力を借りて、一部の競技ではオリンピックの記録を上回ったりすることがあるとのこと）

とすると世界で一番少子高齢化が進む日本がある程度の幸福を甘受し続けるためには、AIとロボット技術の発展が不可欠であるように思う。
（運輸業界の人手不足とか、AIによって緩和できるのではと思う。高速道路での無人トラックのコンボイとか夢が溢れる）

自分のすきなSF小説に、ブルース・スターリングの「スキズマトリックス」という本がある。そのなかに工作者（バイオテクノロジーに特化し自分を改造した未来の人間）と機械主義者（メカトロニクスに特化し自分を改造した未来の人間）の対立が描かれる。日本人はどちらにいくのだろうか？あるいは両方のハイブリッドか？

CI（継続的インテグレーション）を勉強した

CI(continuous integration:継続的インテグレーション)について勉強した。
CIとは、
プログラムの動作を毎日毎晩確認してバグを洗い出しながら開発を進める手法のこと。確認のために日々プログラムのコミット、コンパイル、テストを自動化する。その為ツールを用いて人がいない夜間にそれら確認を実行する。

そのメリットは

1. 日々少しづつ確認を行うことにより手戻りを最小限にする。（最悪でも1日分の手戻り）
2. それにより品質を高めることができる。
3. 自動化により作業工数の削減が可能。
4. 自動化により作業ミスを減らすことが可能。

となる。これは短期間でプロダクトのデリバリを行うアジャイル開発手法ともよくマッチする。

この考え方をさらに推し進めると継続的デリバリ≒DevOps、つまり本番環境へのプロダクトの投入まで自動化することも目指すことができる。

ちなみにスマホゲームなどは、毎日のようにイベントを行ってゲームを盛り上げようとしており、そのために毎日のようにプログラムの修正が発生していると思う。その場合にはこの継続的デリバリの考え方で開発を行わないとやっていけないはずだ。
一方自分が関わることが多いいわゆる「お堅い企業」においてもビジネスにおいて新しいサービスの早期投入を求められるようになってきており、この考え方の導入がだんだん進みつつある。

NoSQLを勉強した

ちょっとかじった程度で曖昧にNoSQLを理解していたので勉強した。
SQL（というかRDBMS）については、これまでそれなりに実務でもやっていたので理解しているつもりではあった。

これまでのイメージでは、NoSQLとは、

1. ACIDを保証しない。
2. リレーショナルな関連付けとデータの最適な保持（正規化）ができない。
3. 便利なSQLを使えない。
4. ただし高速らしい。

とわりとマイナスのイメージから理解していた。当初は、Hadoopあたりから発展した技術と勝手に考えていた。すなわち巨大データを（ペタバイトとか）をつかって分析を行うためによみ出しを重視して、ACIDを保証しないという理解をしていた。

今回勉強してもその理解は、あまり変わっていなくて「本当ならRDBMS(SQL)で間に合わせたいが、データが巨大すぎ、そのうえで高速な処理を求められるため泣く泣くRDBMSの利点をすてて、要件を満たす技術を作り出した。」

という理解です。

近年、クラウド技術が発展して、かつRDBMSもインメモリで動くようになっています。1クライアント（トランザクションといったほうがいいのかな）が1データ（ROW）を読み書きするだけならば、そして、蓄積された巨大データは別途分析するという要件ならば、

NoSQLという選択になるのかもしれませんが、上記のようなクラウドやRDBMS自体の発展に伴い、使用する局面は少なくなってくるのではないかと考えました。（複雑に絡み合うデータを取り扱うケースのほうが圧倒的に多いと考える）

ちなみにポケモンGoはGoogle Cloud Platformで動いているとので、選択したデータベースは、MySQLの派生DB(Google Cloud SQL)かなあと想像する（カスタムで全然別のデータベースも導入できるとは思うがスケールさせるのが大変そう）

NoSQLも大別すると４種類くらいのタイプがありそれぞれ得意不得意がある。

1. キーバリュー型：とにかく早い
2. カラム型：列単位でのデータ操作が得意
3. グラフ型：グラフというのは、関係性の意味で、複雑な関係性の検索・分析などリレーショナルデータベースで表現できないぐらいの関連付けをデータに紐づけられる（例としては道路網における最短ルート探索とか）
4. ドキュメント型：定型的な構造を持たないデータベース（Row毎にデータ構造を変えることができる）

なので要件によってNoSQLを使用していくことも十分考えられるが、既存のRDBMSがNoSQLの機能をどんどん取り込んでいっているので、先行き不透明という印象を持った。

しかしながら、調べていくうちに例えば、Radis（キーバリュー型にちょっとドキュメント型風味）、Cassandra（カラム型）、CouchDB（ドキュメント型）とかに興味を持った。

あとMongoDB（ドキュメント型）も人気があるようだ。

自分は元々オラクルやサイベース（懐かしい）を使ってたのでやはりSQLに親しみがあるが、上記のDBたちも少しづつ触ってみて評価できるようになりたいと思う。

IoTについて勉強した

IoT(Internet on Thing)とは何か？を勉強した。
文字通り、あらゆるものがインターネットに接続されること（冷蔵庫とか家電）と最初は理解していた。で接続して情報を収集して何になるの？と考えていた。

IoTとは、以下のように定義されるらしい。

1. モノからセンサーによっていろいろな情報をインターネット経由で収集する。
2. 収集したデータを蓄積する。
3. 蓄積されたデータを分析する。
4. 分析に従って、必要に応じてモノにフィードバックする。（センサーついているモノに直接フィードバックすることもあれば、分析結果を社会や企業、の今後に生かすことも指すらしい）

センサーから収集し、蓄積したデータは膨大なものになるので、その分析には人工知能も関連してくる。（人知では分析しきれないほどのデータ量になりがちのため）

とすると応用領域は、例えば電力のスマートメーターによって電力の使用量の傾向の蓄積であるとか、自動車からの交通量の状況蓄積と対策とか、自動車事故を起こしやすい状況の分析とか。また医療分野についてもいろいろな応用が考えられる。介護分野についても同様。（しかし金融の投資動向とか分析されると一般人は、大手金融機関の思いのままになるんだろうなあ）

とするとその情報の管理が大変重要になる。各々のデータが個人情報と結びついた時、その個人の生活が赤裸々になってしまう可能性がある。（もうAmazonやGoogle、Appleにはかなりの個人情報を握られてしまっているが）

2016年9月現在、政府から情報銀行なる構想が提言されたが、個人の購買行動や医療情報などは国に握られたくはないとの思いがある。年金の管理のずさんさ、住基カードの有様をみるととても役所に自分の情報を預けたくはないと考える。（マイナンバーを利用したいのだろうけど、ビッグブラザーの影がチラチラ見えて来る）

DevOpsについて勉強した。

DevOpsといえば高速な開発と本番環境へのプロダクトの投入と思い込んでいた。まちがっていないが、もっと広く深い概念と理解した。

2016年現在確立した定義はないが、自分の理解を列挙してみる。

1. Dev（開発）とOps（運用）の協力体制をより密にすること。
2. これまでは、開発の立場としては、開発したプロダクトをより早く本番環境に載せたい。
3. 一方運用側は、安定稼働を望むため変化を好まない。
4. そのような利害関係があるので、企業体として求められる「早くサービスを提供すること」に対応しきれない部分があった。※上記の書き方だと運用側が抵抗勢力のように読めてしまうが、低品質のプロダクトをもってくる開発側にも問題がある。あと本番環境と開発環境の差異などで障害は発生しがちである。なのでコンテナ技術が発達してきたのかな？
5. そのための考え方がDevOpsという言葉に集約される。
6. より密に協力していこうという考え方の背景は、ITをコストカットのためのツールとしてではなく、ITを使って競争に打ち勝つという考え方がある。そのためより便利で安定性のあるソフトウエアプロダクトが求められている。
7. また協力の考え方だけでなく、それを実現するためのツール群も近年現れてきた。
• ツール群によるプロダクト開発（と投入）のレベルに段階があるので少し解説する。さっき覚えた（笑
1. 第1段階　バージョン管理（本番のソースコードと開発中のソースコードの差異管理。）
2. 第2段階　継続的インテグレーション（テストとOKであれば開発系ソースコードへのコミットの自動化）
3. 第3段階　継続的デプロイ（第２段階の結果、問題がなければプロダクトのビルドと本番環境への適用の自動化）
4. 第4段階　継続的デリバリ（本番環境へのデプロイタイミングをビジネス要求に沿って決定する。※第3段階までくるといつでも本番環境にプロダクトを投入できる状態になる）
• 上記の段階を実現するための便利なツール群が近年登場してきた。
8. 欧米ではここ7,8年前ぐらいからこの考え方はあって、日本では自分の見聞きする限りせいぜい第2段階どまり。（スマホゲームだと第4段階まで行っていないとだめだろうけども、毎日のように何かイベントがあるから）

一番重要なのは6.の考え方だと思う、その方法としてDevOpsという考え方が生まれてきたのだと考える。

ITプロジェクトにおけるカンバン方式について勉強した。

「カンバン」というと「トヨタ」しか連想されなくて、生産管理の手法と思いこんていたので改めて勉強した。

カンバンのポイントは以下のとおり
※ちなみにWikipediaは、難しすぎてよくわからなかった。

1. この方式の導入の大きな目的は、プロジェクトの見える化。
2. 何（タスク）を、いつまでに、誰が、今どこまで、を見える化する手法。
3. 最低限、ホワイトボードと付箋紙があれば実行できる。
4. （おそらく一番単純な書き方では）ホワイトボードに縦に３本線を引く。
5. 左の列は「ToDo」何をするのかを付箋紙で貼っていく。
6. 真ん中の列は「Doing」仕掛り中の付箋紙を「ToDo」から移動させる。
7. 右の列は「Done」終わったタスクを「Doing」から移動させる。
8. 付箋紙にはだれが、いつまでに、どんなことをするのかを書く。（はず）
9. ホワイトボードではなく、コンピューターのツールを使ってももちろんいい。
• チームの人数がすこし多くなるとその方が良いのだろうと思う。

上記は、単純なパターンだが列を増やしプロセスを細かくすることも可能。

上記をみて巷でいうチケット駆動では？と思ったがそちらも詳しくないので後日調べてみる。

しかしこれは自分が関わったような大規模プロジェクトでは、導入しにくいのではと思った。やり方に問題があるのではなく「見える化」を良しとしない人がいるためだ。表向きは、「プロジェクトなので見える化は推進されるべき」となるが、実際は見えると困る人達がいる。プロジェクトの進捗状況は、その人自身の評判や人事考課に関わってきたりする。なにしろ一目で「できない人」がわかってしまうので、日本人の性質なのか赤裸々にそれを明確にすることは難色を示されることがあるのではと感じた。

個人的には、ITプロジェクトにおける「できる」「できない」は、向き不向きの問題なので、赤裸々になっても恥じることはないと考えているが。

SEOの勉強会にいってきた

最初にSEO(Search Engine Optimization 検索エンジン最適化)の勉強会にいってきたので記録として残しておく。

全体は２部構成で
1.Webマーケティングの考え方
2.Google Analysticsの概要について
となっていた。２部はツールの簡単な紹介だったので省略する。

１部のWebマーケティングの考え方が非常に面白かった。
例えば、自分が有料自習室（最近は図書館で受験勉強とかしづらい）を経営しているとして、その宣伝のWebサイトにどのように誘導するのか？

カスタマージャーニー（顧客行動と訳すのかな？）という考え方で誘導の方法論をかんがえる。

1. まず顧客像を定義する（ペルソナというそうだ）
1. 例えば浪人生で集中して勉強する為の施設を探している（毎日喫茶店は高すぎる。また長時間いるのは気がひける）という人が顧客像
2. 次にそのペルソナがとる行動を定義する（フェーズとタッチポイントという、行動の際に顧客がどのように思考するかも仮説を立てる。）
1. フェーズ１　浪人生が自習施設を探す。
• タッチポイント１　Webで、「自習室」「無料」「有料」「最寄の駅名」などで検索をかける。
2. フェーズ２　浪人生がヒットした中でHPを開いて中身を確認する。
• タッチポイント２　ヒットした中で上位のサイトを開き、自分の予算、駅近か？どうか、設備などを確認する。
3. フェーズ３　実際に一度行ってみる。
• 条件に合致していた場合、見学の申し込みをする。
3. 上記は非常に簡単な例だが、フェーズ１、２においてどれぐらい顧客に訴求するか？また検索上位に位置するかがWebマーケティングのポイントとなる。
4. 上記の例だと
1. 自分が想定する顧客の検索にヒットしているか？
2. 自分が想定する顧客が求める情報が自身のWebサイトに盛り込まれているか？
3. をツールを使い分析していく。

なのでブログタイトル、副題、記事タイトルなどが非常に重要であるとわかった。

これまで記事タイトルは、漠然と書いていたところがあるので改善していきたいと思う。

※勉強会では触れられなかったが、どれだけ他サイトからリンクされているかも重要じゃなかったかな？

JSONを勉強した

Web越しのデータの受け渡しにJSON(JavaScript Object Notation)という形式が使われると聞いたので勉強してみた。かつてはXMLが主流とおもっていたのが、必ずしもそうではなくなったらしいので勉強しておかねばと思った。（特にJavasScriptを勉強するにあたって）

XMLは構造をあらわすのに便利な形式ではあるが、ちょっと冗長なところがあるとは思っていた。入れ子構造をあらわすには便利だと思う。しかし可読性はそれほど良くないところもあり、単純なデータ構造をあらわすためにJSONという形式ができたのではないかと思う。単純な設定ファイルなどのためには、XMLは大仰なのかもしれない。

JSONの簡単な記載例を以下に示す。

{
    "年齢":50,
    "住所":"東京都杉並区",
    "ペット":["犬","猫","猿","雉"],
    "既婚":false
}

左側にデータ名、コロンで挟んで右側にデータ値。超簡単ですね。
ペットの記載例のように配列も取り扱い可能。記載例には書かなかったが入れ子構造も可能な様子。（オブジェクトというものを使うのかな？今回は割愛）

確かにXMLよりは可読性に優れているように思います。
RDBMSでJSONをサポートしたというニュースを聞くのもなんだかわかる気がします。

SOAについて考えてみた

これまで関わった２つのプロジェクトで基本的なアーキテクチャにSOA(Service Oriented Architecture)を採用していた（とされていた）。

まずSOAとは、概念であり、技術や製品ではないと記述をあるところで読んで、ひっくり返りそうになった。

SOAの概念、利点は以下とおり。

• 業務（領収書を発行する等）単位でプログラムを部品化し再利用できるようにして、システム単位のみならず企業単位で最適化を図る。（例えば組織変更によるワークフロー変更への柔軟な対応とか）もうすこし詳しく書くと、
1. 業務の部品化する。
2. 部品を組み合わせてアプリケーションを構成する。
3. オープンな技術による（SOAP等）標準的なインターフェースを備える。

と理解した。

とすると、関わった２つのプロジェクトは、いずれも（かなり有名な）パッケージ製品を利用することが決まっており、外部からアクセスする為のAPIも当然備わっていた。それぞれのプロジェクトは、別途アプリケーションサーバーを立て、APIにかぶせる形でSOAサーバーを立てていた。（SOAは概念であるとするとSOAサーバーって変な感じ）

パッケージ製品のAPIは、部品化され標準にのっとったインターフェースを備えており、さらにSOAサーバーが必要な理由がよくわからなくなってくる。

真に企業においてSOAの概念が必要なケースは、全く新規にシステムを一から再構築する場合のように感じる。

つまりバズワードであるSOAを営業的に使って、SIerから余計にサーバーを買わされただけなのが真実なのだろうか？

Visual Studio Codeを使ってみた。

node.jsを練習するために、入力補完のあるEditorを使いたいと思った。
クラウド開発環境のCloud9は、結局インストールがめんどくさく諦めて、練習のための環境整備の為に労力を割くのもバカバカしいと思い、割り切ってローカルでIDE(Integrated Development Environment))を使うことにした。いろいろなIDEがあるが今回は新進気鋭のVisual Studio Code(2016/08/15 v1.4 Microsoft製OSS)を使ってみようとインストールしてみた。インストールは凄く簡単でだった。

余談だが商用のIDEも検討してみたが、だいたい300、400ドルもするので断念した。これだけの価格差の価値のある機能なのかわからずチュートリアルのためにそれだけの出費をすることは納得できなかったので諦めた。（グループワーク機能や各種フレームワークへの対応が充実しているように感じたが、チュートリアルそこまでの機能は必要としていない）

node.jsの入門本のチュートリアルをやってみるだけなので、とりあえず20行〜30行ぐらい編集できれば良い。なのでエクステンションはまったくインストールせずにそのままとりあえず使ってみた。４、５年前にはEclipceをPythonの為につかったことがあるが、そのときよりもかなり進化しているように感じた。（Pydevってエクステンションをインストールした記憶がある）

まずチュートリアルの為の簡単なhtmlを作成しておおっと思ったことは。

1. 入力補完がずっと進化しているような気がする。
1. カッコ(){}の補完が便利。
2. タグの候補が2,3文字入力するだけで表示される。（タグ以外の文字列も補完してくれるのかな）
3. Tabの段落下げをかなり自動でやってくれる。
2. Terminalが内蔵されているので、エディタ内で完結できるので良い。
3. ファイルブラウザ（エクスプローラー）がデフォルトで内蔵されている。
4. 思ったよりずっと軽かった（Eclipceはかなり重かった気がする。昔いた現場では現場ではプログラマーは、ロースペックのPCでEclipceでJava開発をしていた。機能はともかく重くてしんどかっただろうなあ。）

まだまだ使いこなしていないが、いろいろ便利なんだろうな。手慣れたプログラマーにとっては基本的な機能でも、おじさんの手習いとして使うには凄く感動した。

開発環境構築でハマる（いきなり高い目標を掲げるのは悪い癖）

勉強のため、ちょっとしたプログラムを作りたいと思い取り掛かったが、ハマる。

やりたいこと

1. どこからでも環境にアクセスできるようにクラウド上に環境を作る。
2. ブラウザさえあれば作業できるようにWebベースのIDEを導入する。

やろうとしていること

1. クラウドは、Vultrを選択。これまでは、DegitalOcianを使ってきたが新たに使ってみることにした。理由は、Tokyoリージョンがあるため、アジアはシンガポールリージョンしかないDegitalOcianよりレスポンスが良いかなと考えた。（ただし出来合いのアプリケーションを一発で入れることができるのはDegitalOcian、インスタンスの作成とかスナップショットからのレストアもDegitalOcianのほうが気持ち早いかな）
2. ディストリはubuntuを選択。理由は使い慣れているから、CoreOSも使ってみたいけど。そこから覚え直すのかなあ。。
3. IDEはCloud9を選択。Amazonに買収されて話題だし、使い勝手が良いと評判。

１、２は超簡単。幾つか選択をしてボタン一発。SSHで接続する。useraddでユーザーを作ろうとするが、デフォルトで/homeにディレクトリ作ってくれなかったっけ？ディレクトリを作成。

３で、必要なもの。

1. node.js
2. python（2.7系列？）

node.jsのインストールはうまくいった。ubuntu16.04はpython3系列しかない？←いまここ

--追記--
やはり16.04からpythonは3系列がデフォルト。

-2016/7/26追記　ubuntu16.04にpython2.7を導入。
node.js + expressまで導入。

-2016/08/09追記
やはり思い直すし上記の環境は破棄することにする。

サーバレスアーキテクチャについて勉強した

最初にの言葉を知った時なんだろうと、？マークが３つぐらい頭に浮かんだ。

いろいろ調べていくにつれ以下のことがわかった。
※クラウドサービスを使う前提。

1. 一般的なWebのシステム構成としては、2層構造となる（アプリケーションサーバー（Webサーバー含む）、データストレージ）
2. しかしサーバーレスアーキテクチャでは、このうちのアプリケーションサーバー層が存在しない。
3. もう少し厳密にいうとアプリケーションサーバーは、（あたりまえだが）サーバーとして常駐し、リクエストを待ち続けている。よって常にCPU、メモリ等のリソースを消費し続けている。
4. サーバレスアーキテクチャによると、プログラムは常には起動していない。リクエストがあった時に起動され、リソースを消費する。
5. 代表的なサービスは、Amazon Lambda

※ただしサーバーがなくなったというよりは、サーバーの存在を意識する必要がなくなったという方がより正確らしい。

メリットは、以下のとおり

1. サーバーとして常に動いていないのでリソースを使わない（コストの削減）
2. スケーリングが楽（サーバレスを実現する仕組みのたまものだとも思うが、サーバー自体をリクエスト量に応じてスケールさせるにはそれなりの仕掛けを構築する必要がある）
3. サーバーがないのでサーバーの運用管理が不要（サーバーが死んでいないかを機にする必要はない）

デメリットは、

1. まだこれからの技術なのであまり複雑な処理には向かないかもしれない。

比較的、静的なリクエストの大量処理に向いているかもしれない。

Dockerを勉強した（その2）

昨日書いたことに間違いがあったので、まずは訂正。


3．コンテナには、さまざまな依存関係のあるアプリケーション群を一つにパッケージングしたものである。（例えばWebサーバー、アプリケーションサーバー、データベースを一つにまとめたもの）

→といった使い方は、あまりしないらしい。Webサーバーで1コンテナ、アプリケーションサーバーで1コンテナというふうに分割して運用するのが普通らしい。

そして昨日の疑問、

疑問1：アプリケーション空間、ユーザー空間の仮想化とは、まだちゃんと理解できていない。どのレベルでDockerEngineは仮想化するのか

→独立したプロセス空間、ネットワーク空間を提供する。（アプリケーション側からは一見１つのOSとして見える。OSより下位レベルのシステムコールとかはできないんでしょうね）

疑問2：環境依存する部分は本当にないのかIPアドレス、MACアドレスとか。DockerEngineがそれを吸収するのか？あるいは環境情報は別途デプロイする必要があるのか？

→仮想ブリッジと仮想ネットワークインターフェースによってネットワーク差異を吸収する。（すごいぜ！）

その他
コンテナ自体の冗長化（クラスタリング）技術は、まだ発展途上にあるらしい（ほんのつい最近そういった技術が発表されつつある）
とすれば、大規模サービス（ブラウザゲームとか）は、OSレベルで冗長化して、その上にコンテナをいくつも載せていく構成になっていくのか？
自分は、これまでレガシーシステムの刷新を多く手がけてきたので、これら技術の基幹システムへの導入例は不勉強にして知らない。このような技術によって大企業の多くが悩んでいる迅速なサービスの提供が可能になる気がします。

Dockerを勉強した（その1）

Dockerについて全然わかっていないので、まずガバッと勉強することにした。
有識者の方には何言ってんだこいつと思われることもあるかもしれませんがご容赦を。

まず今日理解したこと。

1. Dockerとは、コンピューターの仮想環境を構築する仕組みの１種である。
2. Docker（という仕組み）の環境の一つ一つをコンテナと呼ぶ。
3. コンテナには、さまざまな依存関係のあるアプリケーション群を一つにパッケージングしたものである。（例えばWebサーバー、アプリケーションサーバー、データベースを一つにまとめたもの）
4. コンテナとは、OSを仮想化するわけではなく、アプリケーション実行環境の仮想化である。（今日の疑問1：アプリケーション空間、ユーザー空間の仮想化とは、まだちゃんと理解できていない。どのレベルでDockerEngineは仮想化するのか）
5. コンテナは環境依存しないので、開発環境で作成したアプリケーションをそのままデプロイすればそのまま動く（今日の疑問2：環境依存する部分は本当にないのかIPアドレス、MACアドレスとか。DockerEngineがそれを吸収するのか？あるいは環境情報は別途デプロイする必要があるのか？）

Dockerの利点

1. 上記と重複する部分があるが、開発環境と本番環境の差異（CPU、メモリ量、ディスク量などは当然差異がある。しかしそれらはスケーラブルであることを前提にした作りにしておけば良い？）がないはずなので、開発環境のアプリケーションを本番環境にそのままおけば動く（はず）

その他（感想とか）

1. コンテナ技術は、Docker以外にもあるが現在はDockerが主流。
2. 仮想化技術の進歩は目覚ましい。コンテナ以外にも新しい技術がたくさん生まれては消えていっている。過去に確かSun Microsystemsが夢見ていた、どこでもなんでも同じように動く世界がだんだん実現しようとしてきているのか？