kafka サーバーのgraceful shutdown
何かとややこしいkafkaの終了、綺麗にシャットダウンする為の方法です。
起動したいサーバーのプロパティファイル
config/server.properties
の中に
controlled.shutdown.enable=true
を追加します。
終了したい時に
bin/kafka-server-stop.sh
を叩けば綺麗に終了してくれます
kafka: ERROR Exiting Kafka. shutting down と怒られた件
正しく終了されてない/正しく起動されていないkafkaサーバーはプロセスが残り、起動する時に怒られます。
zookeeperに登録されたidを消すか、PIDをgrepして殺してしまいましょう
$ ps aux | grep zookeeper $kill -9 <zookeeper.properties process>
kafkaサーバーを終了してからzoo keeperを終了させるように!
"中国でスマホ決済が流行ったのは現金が機能していないから"は真っ赤なウソ!中国大陸でスマホ決済が流行りだした理由
ニュースでよく
中国はフィンテック先進国~
スマホ決済大国~
等の記事を見ると必ずあるのが
”現金がまともに機能しない国じゃ~”、 ”日本は現金がすばらしいから~”
等のコメントですが、先日ついに某ネットニュースでもそのような発言が見られ、
そう言った考えこそが日本の電子マネー化を妨げている思想だと言うことを訴えたい作者です。
私は2002年~2016年の間北京に在住していた者ですが、
私の実際の経験上、
中国で現金決済が見切られたのは所謂”現金が機能していない”が(主な)理由ではないと断言します。
主な理由ではないと言うのは、中国在住と言え、私は北京しか知らないので地方や田舎では確かにそんな理由が存在したのかもしれません。
ですが少なくとも北京や上海、中国の都会部ではそんな理由で流行った訳ではないのです。
なので私が今回話すのは北京でスマホ決済が流行った理由と取っていただいた方が良いのかもしれません。
中国の’偽札問題
まず背景として、中国の偽札問題。
実在していましたし、酷かったです。
実際に北京に初めて行った時、毎日偽札を見るくらいには横行していました。
首都なのに(笑)
市民はお金を受け取ったら必ず偽札か判断しなければならないし、その習慣がついていました。
ATMから出てくるに関しては私は遭遇したことがないのでわからないですが、あっても不思議ではないですね。
しかしそれは2002年の話です。
少なくとも2008年までは私も偽札問題でとても苦労をしていました。
しかし2008年、北京オリンピックをきっかけに、
偽札が嘘みたいに消えたのです。
具体的な時間は覚えていないですが、
ふと気づいたらもう随分と偽札を見てないなぁと思いだすのです。
(本当に中国政府の力を侮ってはならない)
メンツの為には何でもする所がある国ですから、
政府が何らかの働きを掛けたのでしょう。
少なくとも私も、私の周りの人間もお札を受けっとてまず偽札か確かめる事はなくなりました。
偽札問題は確かに存在します。
地方で北京と同じ状況と言うわけにもいかないと思うので、
地方ではまだまだ横行していたのかも知れません。
しかし北京ではある程度問題はクリアされたように私は考えます。
にもかかわらずスマホ決済は人々の生活に根付きました。
ソフトバンクの電波が悪い~
とニュースで見たら、
ソフトバンクの電波は10年後の今日も悪いのでしょうか?
東京の空気が悪いと20年前は報道されていたのですが、
今日も空気は悪いのでしょうか?
北海道も空気は悪いのでしょうか?
つまりは、過去のニュースにあまり囚われてはいけません。
中国程の大国となると、中心部の北京と地方の田舎とでは一括りに論じてもなりません。
確かに現金が機能していない都市もあったのかもしれません。
ですがそれを日本が出来ない理由にするのはただの逃げです。
じゃあなんで北京でスマホ決済が流行ったのか?
幾つかの背景としての理由と、三つのきっかけがあると私は考えます。
背景1:中国の銀行カードはすべてデビットカード
皆さんDebitカードと言う言葉をご存知でしょうか
普通の銀行カードと違い、店舗側でそのまま使えるカードです。
クレジットの様に使い、口座の残高からそのまま引き落とされます。
使用者にも店舗側にも手数料はかかりません。
口座さえ作れば年齢や審査もなし!超便利です。
なので学生、社会人に関わらず、誰もがデビットカードを持っていました。
チャージももちろん不要、銀行の口座にお金が入っていれば使えます。
私がアメリカ在住仕手いた頃も、銀行の口座カードはすべてデビット機能が付いていました。
何故日本のカードはいまだにただのATM引き出し専用カードなのか不思議に思うくらいです。
なのでスマホ決済初期のころ、ALIPAYもただのスマホ版デビットカードとして使われていました。
特にチャージする必要もなく、デビットカードのパスワードと番号を登録しておくだけでスマホで使えるのですから。
登録難易度も心理的難易度もクレジットしか持たない日本に比べ、けた違いに低いのです。
背景2: 過度のネットショッピングブーム
中国の大手ECサイト、TAOBAOを手掛けるアリババ。
中国で使わない人は居ないと言っても過言ではありません。
北京では日本を遥かに超えるネットショッピングのブームが存在していました。
ショッピングモールはもはや食事処。
モール内で服や靴を試着し、ネットで同じ物を探す。
ネットでは必ず同じ物が低価格で販売されており、誰も実店舗で買い物をしない程になっていました。
(税金のかからない香港からの転売や日本からの転売、工場からの流れ物、偽物やまがい物等同じは複数のリソースがある)
しかもアマゾンは北京で存在感は皆無、すべてTAOBAOから買い物をします。
Alipayのネット版は実はTAOBAOの初期から存在しており、Taobaoで買い物する際必ずアカウントを持っていなければならない。
この様な背景の元、誰もがAlipayのアカウントを持っていたと言えるであろう。
背景3: アリババとテンセントの独占市場、アプリや規格の乱立が起きない
EC2のアリババ、SNSのテンセント。
日本での楽天+アマゾンが中国にとってのアリババととらえていいだろう。
しかも日本人より遥かにネットショッピングに依存しているのだ。
テンセントに至ってはゲームやSNS、qqやwechatを代表に幾度も社会現象を巻き起こした巨人だ。
日本のLine, Dena辺りやガンホーレベルのまとめだと思ってくれていいだろう。
※実はBaiduも少し出遅れてスマホ決済に参戦したが遅すぎた。
その二社がほぼ同時にスマホ決済に乗り出し、巨額な投資を始めたのだ。
他社が追いかける気も起こさない程に。
それによって早期に市場を占拠し、日本の様にLine pay, rakuten pay, amazon pay, yahoo pay......等とサービスの乱立が起こらないのだ。
この現象の中にいる一般店舗の経営者たちはどう思うだろうか。
このブームに乗らなければ次に淘汰されるのは自分だと気づくはずだ。
背景4: 決済手数料0!店舗導入手数料0!
そう、日本で店舗導入が難しいのは店舗側の負担なのだ。
初期費用が掛かるし利用手数料として3%くらい引かれるというのが私が今知る日本のpay市場だ。
しかしアリババ、テンセントはほぼ無料で打ち出している。
店舗側の負担が完全にないのだ。
しかも、店舗用のアプリはない。
私の知る限り、日本のQR決済は個人用と店舗用に分かれており、
そこで手数料が発生して居るのだが、
中国のQR決済は店舗側と言う概念がない為手数料の取り用がないのだ。
それが良いことか悪いことかはわからないが(管理は難しいだろう)、
結果として店舗は特別な申請すら不要で、
レジを通せばあとは従業員の個人アカウントに送金し、後からまとめるシステムになっている。
店舗の負担は圧倒的に少ない。
初期は完全に無料だったのだが、いまは引き落としと一年の送金限度を越えた場合のみ手数料は発生する。
ただし、手数料は1%未満。
そもそも誰も現金を引き落とさないし送金限度を超えてしまうような人にとっては些細な事であろう。
以上が私の知る北京での背景だ。
ただ、私がスマホ決済復旧にとって影響が多いと思う物をピックアップしただけですし、
私の知り得ない所でまだまだ理由は有ったのかもしれない。
巨大な背景の一部だと理解して頂ければと思う。
そして何より恐ろしいのが、三つのキッカケだ。
キッカケ1 出前が二ヶ月間ほぼ無料
今日本で投資が行われているデリバリーフードのプラットフォーム。
LineデリマやUber EATS等と似ていますね。
当時はまだアリババの傘下に入ってなく、アリババから巨額な投資を受けた”饿了么”と、"美团外卖"がユーザの競い合いを開始し、
日本では想像できない程のセールを繰り広げていたのだ。
アプリケーションを開けば近場の出前可能な店がずらりと。
当時私は大学が多い町で暮らしており、庶民的な店がいっぱいだったのだ。
出前可能な店はざっくり60店舗以上あっただろう。
ほぼ毎月同じ物を食べないでいいレベルだった。
初期段階では”饿了么”の独占市場で、
アリペイを使えば半額程度のセールでした。
それでも十分ですよね笑
途中から"美团外卖"が参入し出してきて、セール額が一気に上昇。
”15元で12元分のポイント返還!”
意味わかんないですよね笑
元々安いのですが、それでもセールのお陰で50円くらいで丼とペットボトルが買えちゃいます。
使わないわけがないでしょう。
しかも”饿了么”と、"美团外卖"、どっちもアリペイを使わなければポイント返還が少なくなるシステムな店舗が多かったので
みんなAlipayで支払いしていましたね。
これが初めて大規模なネットショッピング以外でAlipayを使った体験でした。
(流石に半年くらいしたらユーザーも落ちつきセールは略なくなりました。)
これによって少なくとも大学生や若者達はAlipayで支払えば割り勘の問題もなく現金も使わないで済むし便利だなと感じ始めたでしょう。
キッカケ2 タクシー半額
QR決済の最大の利点は店舗側の導入が簡単なところ。
未だクレジット決済が使えなかった中国のタクシー業界にとってはこれ以上ない便利な機能なのだ。
さらに、日本と違い、中国のタクシーは格段に安い。
と言うか中国は交通機関全般がめちゃくちゃ安い。
例えばタクシー。
地方によって中国のタクシー料金は何倍もの差があるのだが、
北京は上海と並び一番高い部類なのは間違えないだろう。
日本で私の家から空港までタクシーで40分前後なのだが、
料金は軽く10000を超えるだろう(タクシー使わなすぎてあんまり記憶にない)
しかし北京で使った場合、40分前後の距離ならば2000以内で納まるのだ。
北京は東京に比べ、大きさのスケールが何倍も違う。
加え地下鉄はそれほど発達しておらず、
やはり東京のようにどこでも地下鉄で行く訳には行かないのだ。
この様な事情の為、中国では社会人、学生ですらバンバンタクシーを使っていた。
道中で走って居るタクシーの数は東京の五、六倍はある気がする。<–(適当
そんななかある日突然、
キッカケ3 スーパー半額
中国にQR決済を体験に行った方々と話した時、
皆なぜ若者だけではなく老人までもがスマホ決済を使って居るのだろうかと疑問を抱いていたようだ。
そうなのだ
日本では年配の方々は現金のみの人が多く、
スマホ決済はおろか、クレカすら持たない人が大半。
にも関わらず、中国の年配者はスマホ決済を使いこなしているのだ。
そのキッカケとなったのが、スーパー半額。
日本と同様、若者は日々仕事に明け暮れ、
自炊する人はあまりいない。
ただ、日本と違い、中国では結婚した後も親と同居する人が多い。
共働きが当たり前なので、子供の面倒もみてくれるし、ご飯も作ってくれる。
親に万が一があった場合もすぐに対処できるので平均世帯は4人以上なのではないだろうか?
まあこれも北京の家の広さや家賃の低さ(過去)があってからの話なのかもしれないが
と言う背景の元、スーパーを利用する人は退職された方々が多い。
そんな中、ある日突然、
最後に
三つのキッカケによって
学生→社会人→年配者
を順に追って取り込んでいった手際、
お見事と感服するしかないでしょう。
もちろん他にもシェアバイクや無人レジの出現もあるのだが、
それらはむしろQR決済社会に乗った方だと思われる。
以上が私が過去数年間北京で過ごしていた時の実体験だ。
現金が原因ではないと言う理由、お分かり頂けたでしょうか?
スマホ決済社会は巨額な投資と、国策と、巨大企業の策略によって成り立ったのだと私は分析します。
しかしキッカケになった出来事もまた、幾つかの背景の元でこそ成り立つ事情であり、
日本で全く同じ事を仕掛けたとしても決して同じ様には行かないだろう。
ただ私が思うのは、
電子決済社会は必ず訪れる。
現金を勝るメリットがデメリットをはるかに上回るからだ。
もし5年後もまだ現金が半数以上の決済で使用されて居るのであれば、
日本のIT業界はそれこそ完全敗北を目に見る事になるだろう。
使い捨てDockerでビルドテスト Mysqlスキーマが入ったdockerを立上げる テスト衝突を回避する
今までは、ビルドする度にテストサーバーに繋いでテストをしていたが、開発人数が増えた為衝突が起きる様になりました。
その衝突を避ける為にdockerを使ったテスト環境を作った話です。
私のプロジェクトはgradleで動いています。なのでテスト環境の時のみ、command lineからdocker起動のコマンドを流してもらいます。
build.gradle:
tasks.withType(Test) { def dockerName = UUID.randomUUID().toString().replaceAll("-", "") exec { commandLine './before.sh', dockerName } System.properties.setProperty("dockerName", dockerName) gradle.buildFinished { exec { commandLine './after.sh', System.properties.getProperty("dockerName") } } }
dockerコンテナの名前の重複を避ける為、UUIDを使ってランダムな文字列を生成してもらいます。
ちなみにUUIDの衝突確率は10^-18以下なので殆ど不可能です(’-’を消しているので私の使用上そんなに低くないが)
名前を作ったらbefore.shに引数として渡してコンテナを起動します。
before.sh:
#!/bin/bash -x docker pull mysql:5.6 docker run -v $PWD/tmp/:/docker-entrypoint-initdb.d --name=$1 -d -e "TZ=Asia/Tokyo" -e MYSQL_DATABASE=test -p 0:3306 -u root -e MYSQL_ALLOW_EMPTY_PASSWORD=yes mysql:5.6
色々引数をつけていますが、起動するローカルポートはランダム、docker内部の3306に紐付けてくれます。
MYSQL_ALLOW_EMPTY_PASSWORDをつけないとrootにランダムなパスワードをつけられます。
-
- nameで先程生成した名前を渡し、起動したコンテナの特定に使います。
tmpの中にはあらかじめ用意したMYSQLのスキーマが入っています。
docker-entrypoint-initdb.dと言うフォルダにマウントしておくと、中身のファイル(ファイル形式には制限があるが)を起動時に実行してくれます。
ちなみにマウント出来るディレクトリ名にも制限があるので公式ドキュメントをよく見ましょう。
dockerの名前はsystem propertyに渡して、プログラム内部からまたコネクションを立てています。
最後に使い終わったコンテナの削除も忘れないように
after.sh:
#!/bin/bash -x docker stop $1 docker rm -v $1
以上でdockerコンテナを使い、ローカルでビルドテストが完結します。
やったね
DockerのVolumeに関して -v --rm -d ゴミが残る問題 コンテナが起動しない
最近Dockerを使い始めたのですが、一つ躓いたのでメモ。
Dockerのコンテナを立上げる時、コンテナとは別に実は裏でボリュームと言う物も立ち上がっています。
(立上げる時に使うイメージによって違うかもしれませんがMysqlを立上げたら勝手に立ち上がるのは確認済みです)
イメージ的にはこんな感じです:
公式ドキュメントより
簡単に言うとVolumeとはDockerコンテナのストレージです。
ローカルディレクトリにマウントしたり、データを読み込んだりするとここを経由しています。
最初は「へぇーそうなんだ」くらいしか思っていませんでしたが、
先週突然コンテナが起動できなくなり、エラーログを見てみたらメモリが足りないと怒られました。
おかしい、メモリもストレージも十分なのに何が起こった
さらに調べてみるとvolumeが立ち上がらないやら
とりあえず今docker内にある物を確認:
今立ち上がっているコンテナ:
docker ps
何もない
今入っているイメージ:
docker image ls
余計な物はなく特に問題なさそう
今立ち上がっているvolume:
docker volume ls
うわぁ死ぬほどでた
絶対これが原因だろおい
でもなんでこんなにゴミ溜まってんだろ
公式ドキュメントを調べてみたらこんなのがあった:
データ・ボリューム
データ・ボリューム (data volume) とは、1つまたは複数のコンテナ内で、特別に設計されたディレクトリであり、 ユニオン・ファイルシステム (Union File System) をバイパス(迂回)するものです。データ・ボリュームは、データの保持や共有のために、複数の便利な機能を提供します。
- ボリュームはコンテナ作成時に初期化されます。コンテナのベース・イメージ上で、特定のマウント・ポイント上のデータが指定されている場合、初期化されたボリューム上に既存のデータをコピーします。
- データ・ボリュームはコンテナ間で共有・再利用できます。
- データ・ボリュームに対する変更を直接行えます。
- イメージを更新しても、データ・ボリューム上には影響ありません。
- コンテナ自身を削除しても、データ・ボリュームは残り続けます。
- データ・ボリュームは、データ保持のために設計されており、コンテナのライフサイクルとは独立しています。そのため、コンテナの削除時、Docker は 決して 自動的にボリュームを消さないだけでなく、コンテナから参照されなくなっても”後片付け”をせず、ボリュームはそのままです。
公式ドキュメントから
コンテナでデータを管理する — Docker-docs-ja 1.9.0b ドキュメント
おいw
勝手に立ち上がってしかもライフサイクルは独立してるとかw
でもまぁ納得。
まとめてみると:
私は普段
docker pull ** docker run ** docker stop ** docker rm ** docker rmi **
こんな感じでdockerを使っているのですが
実はゴミを消しきれていなかったと!
実際は裏で
docker volume create my-vol
って感じな物が起動時に動いており、
コンテナやイメージを削除しても消えないと言う事です。
本来の目的としては、Dockerのデータを永続化する為に作られる物で、
これを使うとコンテナ間のデータのやりとりが非常に楽になるに加え、
コンテナが万一止まったとしてもデータの保存が出来ると言う目的があります。
素晴らしい仕組みだとは思うのだがdockerをボコボコ立ち上げて、
テスト用に使っている今の私の使い方ではゴミが溜まるだけでした。
対処方:
起動する時、runに--rm オプションをつける
以下公式より:
このコマンドはコンテナと、コンテナに関連づけられた全ボリュームを削除します。ただし、ボリュームに名前を指定していた場合は、このコマンドでは削除されません。
と言う事で、使い捨てのコンテナには最適なオプションです。
volumeだけではなく、コンテナもストップした時に削除してくれます。
しかし欠点として、
-d オプションと同時使用ができない
なのでthriftをdocker内で動かそうとかなら良いのだが、
dockerを裏で立ち上げてテストが終わるまで立上げる等の用途では-dオプションが必要とされるので--rmをつけることはできない。
もう一つの対処法:
削除する時、rmに-v オプションをつける
公式では:
-v, --volumes コンテナと関連づけられたボリュームを削除
と紹介されている。
-
- rmとの違いは、起動時ではなく終了じにつけるオプションである事と、起動時に-dコマンドを付けれる所です。
とりあえず解決しました。