2018-12-18

モバイルオーダーサービスのO:derでラーメンを食べてきた

O:derはスマホで飲食店の注文を行い、並ばずに受け取れるというサービスです。

スマホ注文ならモバイルオーダーアプリの「O:der（オーダー）」 www.oderapp.jp

興味を持った理由は、前職のオフィスで願っていたことを実現する仕組みだったためです。

当時のオフィスは30階建てのオフィスビルで、1〜3階に飲食店などが入居しているというよくあるパターン。御昼時はオフィスワーカーで長蛇の列という、こちらもよくあるパターン。自席から注文を行い、飲食店に着いた頃に料理を受け取ることができたら、と考えていたものでした。

時は流れ私はそのオフィスから去りましたが、そんな考えを実現しているアプリがあると知り、早速使ってきました。

アプリを開くと、現在位置から近い順に利用可能店舗が表示されました。うーん、まだ店舗数はそんなに多くないようです。今回は通勤経路にあり、現在地からも近かった大崎のラーメン屋さんに行くことにしました。

f:id:suzusin:20181218215757p:plain:w250

お店の前に行くと、券売機が煌々と光を放っているので若干怯みます。

f:id:suzusin:20181218220401j:plain:w250

この店舗は先程の画像にもあったとおり、着席後に店内で使わなければいけないようです。店内を見ると席数が限られていることがわかり、席の確保までは担保できないよ、ということが察せました。やむ無し。

さて、いざ入店するわけですが、「先に券売機で食券をお求めください！」と言われるのかどうか問題が残っています。

少し考えた結果、スマホを触りつつ（あ、わたしO:derで注文中です。。。）という雰囲気を出しながら着席することにしました。

店員さんはこちらを一瞥すると「お好きな席にどうぞ」と声をかけてきました。

やりました。成功したようです。

席について、メニューを選びます。

f:id:suzusin:20181218221310p:plain:w250

確認画面に移ります。座席の確認はここでありました。

f:id:suzusin:20181218221350p:plain:w250

購入します！ちなみに事前にクレジットカードを登録してあります。

f:id:suzusin:20181218221443p:plain:w250

注文後はアプリで進捗を見守ります。

f:id:suzusin:20181218221549p:plain:w250

待つこと数分...

ついに誰とも会話せず、券売機に触れることもなく、ラーメンが届けられました🎉

f:id:suzusin:20181218221733j:plain:w250

料理が完成するとプッシュ通知が来るとのことでしたが、先に店員さんが来て、その後に通知が来ました。

これはたまたま店内の人数からして、私の注文だと特定できたためと思われます。

また料理の注文・完成はメールでも来ていたので、あとから確認もできます。

ポイントも貯まるようです。

f:id:suzusin:20181218222134p:plain:w250

まとめ

モバイルオーダーサービスのO:derを使ってみました
店舗によってはスマホから事前注文できるので混雑時間帯等かなり便利になりそうです
導入店舗がまだ少ないので今後に期待したいです

2018-11-21

Microservicesの有償の勉強会に参加した話

昨日、下記の勉強会に参加しました。

reedex.connpass.com

無料の勉強会は山程ありますが、有償のものは結構めずらしいです。そういった会だけに、メモを全部ここに書くのはよろしくなさそうなので、気になったトピックと感想を残すまでにします。

まずは以下の記事を元に、アーキテクチャについてのお話がありました。クラサバとかの話はSI時代を思い出して懐かしかったですが、マイクロサービス登場までの流れは個人的には今更メモするまでもないのでスルーしました。

オーケストレーションとコレオグラフィについて

書籍『マイクロサービスアーキテクチャ』でも触れられています。

マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita )

この事例を元に説明を受けると、とてもわかりやすかったです。

RESTful APIの設計の話

Entity Service Anti-Patternに気をつけましょうという話

Entity Services is an Antipattern

API as a Product というコンセプト

https://restful-api-guidelines-ja.netlify.com/

Zalandoはzozoのようなヨーロッパのサービス
APIを提供してサーボパーティに売ってもらうビジネスモデルらしい

とてもしっかりまとまっていて参考になります。ちょうど先月、またマイクロサービスを考慮したうえでAPIを設計・実装する機会があっただけに、もう少し早くこれを知れていたら…

最後のメッセージは、つい忘れがちな話。

APIの設計はその先に利用者がいてそれを使って商売するのであることを忘れずに

講師の川島さんはとても穏やかな口調で、またところどころで考え、解釈する時間の余白があって良かったです。

2018-11-17

Markdownでスライドを作れるMarpを使って、社内勉強会でDockerの話をしました

毎週末の社内勉強会、弊社は若手の子が思い思いの発表をすることが多いです。それはそれで良いのですが、そもそも自分たちが開発に使っているものの理解を深めるのも良い機会かなと思い、話をすることにしました。

また弊社のサービスはマイクロサービス化の道半ばであるため、コンシューマサービスのみがECSを使ったモダンな環境。それ故に同じ開発部のエンジニアであっても担当業務によってスキル差があることが気になっており、とりわけDockerは“なんとなく”使っている人が多いと感じられたので、今回のテーマに選出しました。

当初は勉強会駆動で自分でも学習をして、k8sの話をしようと思っていたのですが、前述の理由から順番に攻めることにしたのです。

それともう1つ、今回はMarkdownでスライドを作成できるMarp を使って時短でスライドを作成しました。これまではKeynoteを多用してきており、凝り性の性格と相まってスライドが綺麗と言って頂くことも多かったのですが、綺麗でも中身が薄くなるよりは、確実に時間を割いて来てくれた人に価値を届けたいと思い、時間のかけ方を変えました。

f:id:suzusin:20181117200332p:plain

今回はみんなが“なんとなく”使っていることを課題として設定したので、なぜ便利で使うのかを理解してもらうことと、日頃の業務ではあまり触れる機会がない（が、今後マイクロサービス化が進むと触れなければならない人たちに）触れる機会を増やしてもらうことを目標にしました。

やはりハンズオンは楽しいという声があったので、swarm, docker-compose, k8sと連続モノとして続けていければ理解が深まるかなと思いました。

また、Markdownで書いたことで、こうしてこのままblogにも貼り付けることができるのでアウトプットにもしやすいので良かったです。

2018-10-04

Mercari Tech Conf 2018 に参加してきました。

f:id:suzusin:20181004191659j:plain

所感

今年始めて参加しましたが、とても良かったです。
自社サービスのマイクロサービス化を推進しているエンジニアとしては参加しないわけにはいかない！という気持ちで2,000円のチケットをポチッたわけですが、現在進行系でマイクロサービス化に取り組んでいる事例の詳細を知ることができて、安いくらいでした。
またメルカリさんほどの会社でもこういったところは難しいんだ、とか知れて勝手に励まされたり
これを活かせるように、もっと頑張ろうと思える1日でした！

その他

機械学習とMicroservicesという2つの軸があるわけですが、部屋がたまに入れ替わるので満員御礼や空席が目立ったり
- 立ち見はちょっとつらかった。事前にどのセッションに興味があるかを申請して不確実性を除去したい
ドリンク、軽食のコーナーは嬉しい！けどそのフロアで座る場所がないので、正直ちょっと疲れた
- おそらくブースに立ち寄って欲しいということなのだろうけど、人が多くて近寄れなかったり、聞こえなかったり…
昼休みなど、だいぶ待ち時間があったので、ディスカッションコーナーとか交流の場がもっとあると良かったかも！

スライドは後日公開されるとのことなので期待して待ちつつ、ここには手元のメモを一部残しておきます（英語版は既に公開されています）。

Microservices Platform at Mercari

現在300人のエンジニア→2020年までに1000人を目指している
書籍からの引用によると、High performers の組織だけが人数に比例してデプロイ数を増やすことができる
- 逆に、Low performers の組織は人が増えても減少する
Organization design が大事
- システムをマイクロサービスにしても、Backend team がそのままだと、Ownerが不明瞭になる
- QA teamがそのままだと、そこがボトルネックになり、リリースペースが落ちる
- これまでの専門性によるチーム分割では、サイロ化が進む
- 1人1人のエンジニアが多くの役割を担う必要があるが、これは期待しすぎだと感じている
メルカリでは、各チームのエンジニアを助けるためにMicroservices Platformチームができた
- そのサポートもあって、1年前はマイクロサービスは1プロジェクトだったが、現在はプロダクションで19サービス、70サービス以上が開発中

API Gateway Architecture

api gateway on k8s
- 新たな機能はapi gatewayを使って開発する
- 次に既存のモノリス APIをapi gateway利用に置き換えていく
- 新しいサービスはk8sにデプロイ、これによりインフラオペコストの削減ができた
Template projectを作成した
- phpから、golangに移りつつある
- template projectをコピーするだけで最低限のマイクロサービスプロジェクトをすぐに開始できる
インフラ
- これまではSREしかインフラにアクセスできなかった
- 各チームが自由にインフラに触れるようにする必要がある
- 各チームのエンジニアは、cluster adminとして自分たちのサービスの安定運用の責任を持つ

Web application as a microservices

JP Web Re-architect team が発足
Goal
変更に強い柔軟なアーキテクチャ
- TS, React, NEXT, GraphQLを一番最初に選択 する
開発チームのスケーラビリティ向上
- エンジニアの増加に耐えるアーキテクチャ
- 各チームの技術選定を自由に
- フロントエンドは、US+JP 4人から 16人に増えた

現実はSingle PHP Server、理想はチームごとに自由な技術選定、意思決定を。

How to…

Renewalではなく、Re-architect
小さいスコープで行う
小さい成功か失敗を繰り返すことでノウハウを蓄積

移行順の決め方

難易度が低いもの
他改修とのバッティングがないもの
充分なトラフィックがあるもの
- これはマイナーページだと影響を図りづらいため

最高の開発に向けて

技術スタック、新しい挑戦をしている、ドラスティックな変化がある
マイクロサービス化は最高の開発に向けた種まきに過ぎない

2018-06-07

dockerで立ち上げているSolr の JMX 機能を有効にしてモニタリングする

Solr備忘録シリーズ #2

Solrのモニタリングについては以下のQiitaが素晴らしいです。

Solr のモニタリングに使えるソフトウェア

上記でも触れられていますが、
jconsoleによるモニタリングは簡単なグラフだけですが、すぐ使えます。

まず、18983ポートを使うので docker-compose.yml にポートマッピングを追加します。

     - "18983:18983"

そして、JMXを有効にするため、以下を environmentに追加します。

- "ENABLE_REMOTE_JMX_OPTS=true"

こんな感じになりました。

  solr:
    image: solr
    ports:
     - "8983:8983"
     - "18983:18983"
    volumes:
     - ./solr/data:/opt/solr/server/solr/mycores
    restart: always
    environment:
     - "SOLR_JAVA_MEM=-Xms1024m -Xmx1024m"
     - "ENABLE_REMOTE_JMX_OPTS=true"

コンテナを立ち上げ直すと、JVMのArgsに関連する値が表示されるようになります。

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.local.only=false
-Dcom.sun.management.jmxremote.port=18983
-Dcom.sun.management.jmxremote.rmi.port=18983
-Dcom.sun.management.jmxremote.ssl=false

こんな感じ。

f:id:suzusin:20180606001942p:plain

続いて、ローカル端末にjdkをインストールします。今回は最新の1.8を入れました。

$ java -version
java version "1.8.0_101"

ただ jconsole と打ってENTERで立ち上げます。

szk416s-MacBook-Pro:~ szk416 $ jconsole

Remote Processで localhostの18983ポートに接続します。

f:id:suzusin:20180606002448p:plain

警告が出ますが、まぁここでは Insecureで繋げにいきます。 f:id:suzusin:20180606235533p:plain

しかし、 localhost:18983 (disconnected) と言われてしまいました。再接続を聞かれますが、リトライしても変わりません。

The connection to localhost:18983 did not secceed. Would you like to try again?

f:id:suzusin:20180606235942p:plain

どうやらhostのIPをセットする必要があるようです。

参考：あるホストのみjmx監視ができない | 日本Zabbixユーザー会

試しにローカル端末でIPを確認して、とりあえずハードコードですがセットしてみます。

szk416s-MacBook-Pro:~ szk416 $ ipconfig getifaddr en0
192.168.0.11

  solr:
    image: solr
    ports:
     - "8983:8983"
     - "18983:18983"
    volumes:
     - ./solr/data:/opt/solr/server/solr/mycores
    restart: always
    environment:
     - "SOLR_JAVA_MEM=-Xms1024m -Xmx1024m"
     - "ENABLE_REMOTE_JMX_OPTS=true"
    command: "-Djava.rmi.server.hostname=192.168.0.11"

コンテナを立ち上げ直し、再接続します。

すると…

f:id:suzusin:20180607000920p:plain

接続に成功！

これでモニタリングができるようになりました。

2018-06-06

docker-compose.yml で Solr の JVM-Memory を変更する

最近よくSolrを触るので備忘録です。

とりあえずSolrを使うだけなら、docker-compose.ymlに以下のように書いてupすれば、imageが無ければ持ってきてくれて、立ち上がるかと思います。

  solr:
    image: solr
    ports:
     - "8983:8983"
    volumes:
     - ./solr/data:/opt/solr/server/solr/mycores
    restart: always

upしたらlocalhost:8983にアクセスすれば、すぐに管理画面を確認できます。

f:id:suzusin:20180605001534p:plain

このとき画面の右下に出ているJVM-Memory はdefaultの512MBです。

コンテナに入って /opt/solr/bin/solr.in.sh を見ると、以下の設定がコメントアウトされていました。

 #SOLR_JAVA_MEM="-Xms512m -Xmx512m"

おそらくここでも変更できるのだと思いますが、ymlからの方が簡単です。

environmentに追加します。ここでは1024MBにしてみます。

  solr:
    image: solr
    ports:
     - "8983:8983"
    volumes:
     - ./solr/data:/opt/solr/server/solr/mycores
    restart: always
    environment:
     - "SOLR_JAVA_MEM=-Xms1024m -Xmx1024m"