年別アーカイブ: 2018年

オライリー Kafka

オライリーのKafka。Kafka自体はちらほらと聞きつつも、MQ、JMSなどの所謂メッセージングとの違いがさっぱり分からなかったものの、一方でレプリケーションソフトとして使いたい話もあり、体系的に整理したかったところ。

その点、まえがきに整理されていました。

Kafkaはもともと、Linkedin社内のインフラシステムとして始まりました。私たちが思っていたのは、実に単純なことでした。データベースといったデータをストアするためのシステムはたくさんありましたが、自分たちのアーキテクチャにはデータの連続的なフローを処理するのに役立つものがかけていたのです。Kafkaを作る前、メッセージングシステムからログ集約/ETLツールまで、出来合いのソフトをいろいろと試してみたのですが、どれも求めていたものではありませんでした。

結局、私達はゼロから作ることにしました。リレーショナルデータベース、キーバリューストア、検索インデックス、キャッシュなどのように膨大なデータの保存にフォーカスするのではなく、連続的に生成されて成長し続けるストリームとしてデータを扱うことにフォーカスしました。

(中略)

私たちはKafkaをストリーミングプラットフォームとして考えるようになりました。ストリーミングプラットフォームとは、データの発行(Publish)と購読(Subscribe)、保存、処理を可能にするシステムであり、Apache Kafkaはまさにそのために作られています。

(中略)

Kafkaはメッセージングシステムと似ています(中略)、違いは3つあります。第一にKafkaはクラスタとして動作するモダンな分散システムです。拡張することで、超巨大な企業であってもすべてのアプリケーションを扱うことができます。(中略)対ににKafkaは好きなだけデータを保存できるように作られた、真のストレージプラットフォームです。真の配送保証を提供しているため、接続レイヤとして使うと大きなメリットがあります。データは複製され、永続化され好きなだけ手元においておけます。最後に、ストリーム処理の世界は抽象化のレベルを大きく高めてくれます。ほとんどのメッセージングシステムではメッセージの配信しかしてくれません。それに対して、Kafkaのストリーム処理は、はるかに少ないコートであなたのストリームから派生したストリームやデータセットを動的に計算することができます。

(中略)

わたしたちがKafkaを設計/構築する際の森ベーションの1つだったのは、KafkaをHadoopのリアルタイムバージョンと考えることでした。

(中略)

Kafkaと比較される領域の最後は、ETLあるいはデータ統合ツールです(中略)。Kafkaは、あるシステムからデータを取り出して、別のシステムに入れるためのツールではありません。リアルタイムのイベントストリームを中心としたプラットフォームです。つまり、出来合いのアプリケーションやデータシステムに接続できるだけでなく、同じデータストリームをトリガにした独自のアプリケーションを構築して動かせるのです。

内部の仕組みは明るい資料があった。

めざせ!Kafkaマスター ~Apache Kafkaで最高の性能を出すには~

 

事例としてはMQ代替が多く、まえがきのコンセプトと合致しないのが多数だっだけれども、以下が腑に落ちる。
大手ヘルスケアIT企業 Cerner社のKafka活用事例

さて、読書。。。

Google流 疲れない働き方

疲れる職場なので、購入。以下、良いなぁと思ったところ。

Googleではミーティングは基本的に25分単位で行われうようになっています。なぜ30分ではなく25分かというと、他の部屋に移動するための時間なんですね。

会議の開始を0分スタートではなく、いつも5分スタートとしていて、その5分はPCログインして、プロジェクターを立ち上げる時間にしていたけど、似たような話を聞いてちょっと自信となりました。

「すぐに反応しない癖をつける」「反射」で仕事をしない

メールの応答で即レスしないケースが正直個人的には多くて、まとめてあとで対応するものはフラグを立てたりしてるんだけれども、スピードが遅いことにいつも悩んでいました。ただ、こういう手もあるんだなと考えさせられました。頭にくるメールを即レスしないは、たしかによく実践してるw。

疲れる組織「忖度が多い」「役割も期待されていることも曖昧」、疲れない組織「わからない」ことは「わからない」と言える、「役割と期待が明瞭」

確かに忖度多いかも。上司の意見を気にする組織というか。そして疲れない組織は目指しているし、公言しているけどものの果たしてメンバーは言える状況となっているか。。。また期待は明瞭だが、役割が明瞭かと言われると怪しい。

 

ピョートルさんの本は2冊めだけど、この手のビジネス書にありがちな読んでいて普通〜で終わらず、いつも琴線に触れる何かがあり、ちょうど今の私には良い感じ。飲みにケーションを推奨していたりするのも外国籍の方は絶対しないと思っていたのでおどろき。次はNEWエリートは読ませていただきます!

暖かさにつつまれた良い本でした。

最近読んだ本を俯瞰して見る

Oracleのインストールの応答があまりに遅いので物思いに耽る。

 

いずれもオンプレ手作りの世界でも概念はあったけれども、論点が大きく変わってる。

整理してみると、気がつけば一本柱が通る訳で、知識レベルアップした気がしないでも無いが手を動かせる訳でも無いので、田舎の大将的な感じ(でも、積み上がりはある!!)。ビッグデータも、そろそろ整理できそうだけれども、いかんせんプログラムを書いてみないと分からない気がする。。。

読んだ時はふ〜ん、当たり前の話じゃない?だけれども概念だけ読んでも正直分からない。実現するプロダクトとセットで見て初めて分かる。結局、速攻サービスを立ち上げて不要になったら停止すれば良くて、Kubernetes、Dockerとペアで解釈かつ運用しないと分からん世界もあれば、WASであればLibertyProfileで軽微実現できる範囲も指すような。

基盤もといプラットフォーム屋さんであれば読んでおいてほしくて、共通基盤(死語)を宣うお山の大将ならなおさら。でも結局イメージ配布で終わってしまう。

イメージ配布された環境をどうやってプロダクション環境へ移行していくのかって話。ステージングやらローリングアップデートやら・・・。

(クラウドじゃなくて良いんだが)、日本的に言えば保守開発の現場、をモダンに定義した本。うちの会社的に目指せたら良いなぁと思いつつも仕事の95%が報告だけで済む官僚機関じゃ無理だわさ。

読書開始ももはや前述したいずれを繋ぐ世界、で完了。

明日届く、楽しみ。

Oracle GridInfrastructure 12.1.0のインストールでハマってる件

こいつを参考に実施も製品のインストール時にハマった。

情報: /usr/bin/ld: /u01/app/12.1.0/grid/lib//libnls12.a(lxhlang.o): シン
ボル ‘__tls_get_addr@@GLIBC_2.3’ への未定義参照です
/usr/lib64/ld-linux-x86-64.so.2: error adding symbols: DSO missing from command line

・/u01/app/12.1.0/grid/lib/stub の削除
・/u01/app/12.1.0/grid/rdbms/lib/env_rdbms.mk の編集(-lonsを追加)

RMAN_LINKLINE=$(LINK) $(OPT) $(S0MAIN) $(SSKRMED) $(SKRMPT) \
$(LLIBDBTOOLS) $(LLIBCLIENT) $(LLIBSQL) $(LLIBPLSQL) \
$(LLIBSNLSRTL) $(LLIBUNLSRTL) $(LLIBNLSRTL) \
$(LLIBSLAX) $(LLIBPLSQL) $(LIBPLCN) $(LINKTTLIBS) -lons

にて回避できたら今度は以下エラー

情報: /usr/bin/ld: /u01/app/12.1.0/grid/lib//libclient12.a(kpue.o): シンボル ‘ons_subscriber_close’ への未定義参照です
/u01/app/12.1.0/grid/lib/libons.so: error adding symbols: DSO missing from command line

同じく、・/u01/app/12.1.0/grid/rdbms/lib/env_rdbms.mk の編集(-lonsを追加)

PLSHPROF_LINKLINE=$(LINK) $(OPT) $(PLSTMAI) $(SSDBED) \
$(LLIBCLIENT) $(LLIBPLSQL) $(LLIBSLAX) $(LLIBPLSQL) $(LINKTTLIBS) -lons

次は・・・

情報: /usr/bin/ld: /u01/app/12.1.0/grid/rdbms/lib/houzi.o: シンボル ‘ztcsh’ への
未定義参照です
/u01/app/12.1.0/grid/lib/libnnz12.so: error adding symbols: DSO missing from command line

同じく、・/u01/app/12.1.0/grid/rdbms/lib/env_rdbms.mk の編集(-lnnz12を追加)

TG4PWD_LINKLINE= $(LINK) $(OPT) $(TG4PWDMAI) \
$(LLIBTHREAD) $(LLIBCLNTSH) $(LINKLDLIBS) -lnnz12

ただ、このあとも

PRCZ-2012 : node1構成が始まりました

が全く帰ってこない・・・。帰ってきたら

2018/03/24 23:27:29 CLSRSC-330: Adding Clusterware entries to file ‘/etc/inittab’
2018/03/24 23:29:35 CLSRSC-214: Failed to start ‘ohasd’
Failed to start the Clusterware. Last 20 lines of the alert log follow:
2018-03-24 23:26:55.648:
[client(31726)]CRS-2101:The OLR was formatted using version 4.

The command ‘/u01/app/12.1.0/grid/perl/bin/perl -I/u01/app/12.1.0/grid/perl/lib -I/u01/app/12.1.0/grid/crs/install /u01/app/12.1.0/grid/crs/install/rootcrs.pl -auto’ execution failed

Execution status of node1 is:true
Execution exit code of node1 is:256

情報: *********************************************
情報: すべてのノードでrootスクリプトを実行に失敗しました。
情報: Overall status of execution of root/configuration scripts : failed
情報: Shutting down OUISetupDriver.JobExecutorThread
情報: クリーンアップ中。お待ちください…
情報: All forked task are completed at state setup
情報: Completed background operations
情報: Moved to state <setup>

 

ohasd(Oracle高可用性デーモン)を手動で設定して起動。。。

#vi /etc/systemd/system/ohasd.service
[Unit]
Description=ohasd daemon

[Service]
ExecStart=/etc/init.d/init.ohasd run > /dev/null 2>&;1

# systemctl daemon-reload
# systemctl enable ohasd.service
# systemctl start ohasd.service

まだまだどツボ

CRS-4133: Oracle High Availability Services has been stopped.
CRS-4124: Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.
2018/03/25 00:48:41 CLSRSC-119: Start of the exclusive mode cluster failed
2018/03/25 00:48:42 CLSRSC-198: Initial cluster configuration failed
The command ‘/u01/app/12.1.0/grid/perl/bin/perl -I/u01/app/12.1.0/grid/perl/lib -I/u01/app/12.1.0/grid/crs/install /u01/app/12.1.0/grid/crs/install/rootcrs.pl -auto’ execution failed

ここはohasdがちゃんと止まってなかったのでKILLしてクリア。次はこれ

2018/03/25 01:40:10 CLSRSC-365: Failed to create credentials for ASM on the local node

/etc/hostsでIPv6のエントリがあったのでコメントアウト

「rootcrs_node1_2018-03-25_10-56-44AM.log」を確認

 

2018-03-25 11:00:10: kfod op=credremote rc: 256
2018-03-25 11:00:10: Failed to create credentials for flex ASM, error:

——————————————————————————–
================================================================================
KFOD-00319: No ASM instance available for OCI connection
KFOD-00105: Could not open pfile ‘init@.ora’

2018-03-25 11:00:10: Executing cmd: /u01/app/12.1.0/grid/bin/clsecho -p has -f clsrsc -m 365
2018-03-25 11:00:10: Command output:
> CLSRSC-365: Failed to create credentials for ASM on the local node
>End Command output
2018-03-25 11:00:10: Executing cmd: /u01/app/12.1.0/grid/bin/clsecho -p has -f clsrsc -m 365
2018-03-25 11:00:10: Command output:
> CLSRSC-365: Failed to create credentials for ASM on the local node
>End Command output
2018-03-25 11:00:10: CLSRSC-365: Failed to create credentials for ASM on the local node

困りはててとりあえず/u01/app/12.1.0/grid/gpnp/seed/asm/credentials.xml を退避

VirtualBoxでドハマリした件

多分にもれずハマった。

ホストOSはMac OS(High Sierra)、ゲストOSはOracle Linux7

端末はMacBookPro

ネットワーク設定でブリッジ接続でインターネット接続させようと試みるも大ハマリ。

結論はネットワークアダプターの名前設定。bridge0だと通信不可でen0:Wi-Fi(AirPort)だとOK。ここの名前はホストOS端末のデバイス名に依存しているんだと推測。

Mac High SierraにMongoDBをインストールした件

参考は本家。https://www.mongodb.com/download-center?jmp=nav#community

まずはHomeBrewのインストールから、まだMacBookProに入れてなかった。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

続いてインストール

$brew install mongodb

データディレクトリの作成

$mkdir -p /data/db

起動

$mongod
(中略)
2018-01-02T00:13:29.787+0900 I NETWORK  [initandlisten] waiting for connections on port 27017

INSERT

use apa;
switched to db apa
db.user.insert({
... "name" : "Mike Mikowski",
... "is_online" : false
... });
WriteResult({ "nInserted" : 1 })

SELECT
db.user.find()
{ “_id” : ObjectId(“5a4a51a2276a68da5dd5a720”), “name” : “Mike Mikowski”, “is_online” : false }

シングルページWebアプリケーション

たぶん3年くらい前に買った気がする。当時は基盤専任ではなくてJavaScriptも見る部隊だったけど、やっぱりさっぱり分かってなかったなぁという事が改めて分かった。ようやく超ななめ読み(何回目?)でサンプル動かしてひとまず読了。

そもそもSPAという言葉がいつ出たのかは知らないけれども、担当していたシステムでは2013年ごろに開発開始したので、その頃にはもう考え方が整理されていたんだと思う。jQueryやらAJAXという文脈で語られるケースが多かったけど。

本書では、HTML+CSSで画面デザインを作り、クライアントサイドのアプリケーションを組むところ、サーバサイドをNode.jsを使って作るところ、MongoDBはJSON格納する文脈からお手軽なドキュメントDBとして紹介。

でも一番のミソはその一連の流れ、特にSPA、クライアントアプリケーションの考え方の戦略があるところだと思う。

ちゃーーーんと読んで理解したい気もするが、最近はWeb屋さんの世界を離れているのでJavaScriptを突っ込んで学習する気がちょっと引ける。

でも、Node.jsはちゃんと抑えておかないとインフラ屋としてもまずいなぁという思いも。従来はJavaScriptーJava、クライアントサイドーサーバサイトで別スキルセットが必要だから、、、という前提での開発が多かったけど、Node.js使ってドキュメントDB使って、MongoDBでいいじゃんってなりそうだし。。。

修行不足ですが、どっかのベンダーに担がれて、WebLogic/WebSphere+ドキュメントDBってのには疑問を持てるようにはなりました^ー^