ラスコー洞窟壁画展を見に行ってきた

世界最古の洞窟壁画…では、なかった

東京上野の国立科学博物館で行われているラスコー洞窟壁画展を見に行きました。
教科書に載っている有名な壁画だったので、勝手に勘違いしていたのですが(あるいは、教科書が発行された時点では正しかったのか)、世界最古というわけではなかったのですね。
ウラン・トリウム年代測定法 (原子の崩壊具合を測定して壁画がいつごろ作られたのかを推測する方法)で測った結果、ラスコー洞窟壁画は今から約2万年前に描かれたものであるとされています(測定法に興味がある方はこちらの論文)。

最初に、感想を述べると、「想像以上に写実的で洞窟という暗い空間でよく火を灯しながら精巧に描いたなぁ」と思いました。当時のクロマニョン人は何を思ってこの壁画を描いたのかを考えると想像が広がります。
クロマニョン人は最古のホモ・サピエンスと呼ばれておりますが、同じ時期に絶滅していたネアンデルタール人と混血し、現在の人類はその双方のDNAを受け継いでいるのだそうです。



実は同じフランスにより古い壁画がある

ラスコー洞窟壁画はフランス南西部のヴェセール渓谷で犬と遊んでいた子供が1940年に偶然見つけたものです。しかし、実は同じくフランス南東寄りのアルデシュ県で洞窟学者によってショーヴェ洞窟壁画が1994年に発見されました。
こちらも年代測定を行ったところ、ラスコー洞窟壁画よりもさらに古い、約3万5000年前のものだと発覚しました。この地域は地質やプレートの関係上、壁画や彫刻が保存されやすいため、これほどまでに古い遺産が今も残るのですね(ちなみに、世界遺産が多い国はヨーロッパに集中している)。

Wikipedia-ショーヴェ洞窟- より引用

最近、さらに古い壁画がインドネシアで発見された

2014年、インドネシアで革新的な発見がありました。それが、現在、最古の洞窟壁画であり、最古の芸術作品とも言われるプレイスト洞窟壁画です。こちらも同じくウラン・トリウム年代測定法で測ったところ、約4万年前の壁画だとわかりました(論文はこちら)。

この発見は様々な意味において画期的で、
1. かつての人類(アフリカから世界中に散り散りになった)はインドネシアにも存在し、壁画を描く文化水準を持っていた(日本人の祖先の可能性がある)
2. 壁画の水準がヨーロッパのものと同じような水準であり、「芸術の起源はヨーロッパにある(どや」という論説が覆された
3. 当時、情報をやりとりする手段はなかったことから、ヨーロッパであれ、アジアであれ、ヒトはモノを描きたがるという生き物で、何も参考にしなかったら同じ水準の絵を描くということ
が分かりました。

Pleistocene cave art from Sulawesi, Indonesia (M.Aubert, et.al)より引用

2万年前、神は存在しなかった

当時の壁画を見ていると描かれる対象は動物や人に限られており、まだ神様のような存在は認識していなかったのではないかと推測します。そう考えると、現代の宗教が論理のベースにしている 「昔、神様が云々かんぬん…」という話は一体何なのか再考させられます。
また、国立科学博物館の「人類の進化展」でも記載がありましたが、昔の人類は様々な場所やホモ・サピエンスではないネアンデルタール人とも混血しているため、人種の違いというのは本来存在しないものだということは一考の余地があります。

参考URL

Cloud Foundry vs Kubernetes

PaaS をどう使い分けるのか?

最近、Cloud Foundry(CF) と Kubernetes(k8s) に注目しており、PaaS や CaaS などと言われたりして、実際、何が異なるのかを整理する必要があると感じました。
正直、エンジニアとしては名称などどうでもよくて、これらのツールをどう使い分けたら機能するのかというところに興味があるわけです。

そんな中、CF,k8s の両方のコミッターだった KarlKFI さんがStack Over Flow で答えていた内容が参考になったため、翻訳と自分なりの整理を試みたいと思います。

*そもそも CF, k8s がわからんぞという方は、
CF: jakopenさんのスライド

k8s: コンテナ管理システム「Kubernetes」について調べてみました

を参考にされてみてください。

Cloud Foundry vs Kubernetes

CF では Application PaaS, k8s は Container PaaS (あるいは CaaS) と呼べるでしょう。
CF では内部的にコンテナが使いますが、それをユーザには意識させません。そして、アプリケーション開発に主眼を置いているため、ビルドパックやOrg, Spaceによるユーザごとのアプリケーション管理が可能です。

一方で、k8s はアプリごとコンテナ数やDockerファイルから直接コンテナを作る機能などのように、k8s上のコンテナに直接影響を与えるような設定をユーザが設定できるようにしています。

しかし、これらの境目は技術的な流行りによって変わりつつあるところで、
* CF が Docker Image を実行できるようになる(かも) Lattice accepts Docker images
* Kubernetes が Docker Image を生成できる機能を追加する(かも) Open Shift
また、k8s を生み出した Google も CFのgold sponserになる など、これからの動向は予想できません。

細かい箇所で異なる点では、
k8s:
1. コンテナの集合であるPod(仮想NICを共有する)自体をスケールすることができる
2. コンテナのイメージを直接デプロイできる
3. OSSのコミュニティが CF より大きく活発 (訳注:これは指標がわかりません。githubのコミッターは CF の方が多いです CF k8s
4. 拡張性が高く、3rdパーティーのプラグインなどを追加できる
5. Web GUI もある

CF:
1. 認証機能が成熟しており、ユーザのグループ分けなどがサポートされている(Org, Space, Role などを設定)
2. 開発したアプリ(php, node.js, python,… のフレームワークを使ったものなど) をデプロイできる
3. ロードバランシングの機構が含まれている(k8sも実装が進んでいる)
4. bosh で k8s と同じようにコンテナのオーケストレーション(デプロイやライフサイクルの監視)が行われている
5. ログやメトリクス(グラフ描画するためのデータ)の集積が行いやすい
6. Web GUI は エンタープライズから提供されることが多い

CF bosh vs k8s

CF と k8s を比較すると上のような話になりますが、実は CF には bosh と呼ばれるオーケストレーションツール上で動作させるため、この bosh と k8s を比較したほうが技術的には妥当な感じがします。

bosh は CF の App だけではなく、様々なコンポーネントの面倒も見ています。また、多種類のIaaS(例:OpenStack, VMWareやvSphereなどなど)上で動作できます。
ただし、boshのコミッターである KarlKFI も「悪夢のように使い方が難しい」 ツールとなっているようです。

一方で、k8s 自体をデプロイする際の抽象化はまだまだ甘いところがありますが、改善はされているようです。
例えば、k8s をDC/OS 上にワン・コマンドで展開する機能が実装されたりしているようです。

結局、どう使い分けるの?

プラットフォームを構築する側からすれば、技術的に似た(コンテナのオーケストレーション)ことを行うため、構築する難しさは乗せるIaaS層やネットワーク、社内の事情によって変化するでしょう。
そのため、目を向けるべきは 誰がPaaSを使うのか? ということです。例えば、簡単なアプリを新規に作ってサクッと公開したいという場合に、Docker Image を用意して、コンテナの設定を行って、…という k8s より CF の方が向いているでしょうし、反対に複雑で大規模な構成のシステムや昔作った秘伝のタレ的なDocker Imageをリリースして、コンテナの調整をしてしまいたいという場合には、k8s の方が向いているでしょう。

もちろん、いつどのような機能がそれぞれのプラットフォームに追加されるのかがわからないため、常に動向を調べる必要がありますが、PaaSを使う人の目線で考えるというのは欠かせない点かなと思いました。