If today were the last day of my life

駆け出しエンジニアの備忘録

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の設計はその先に利用者がいてそれを使って商売するのであることを忘れずに

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

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

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

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

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

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

f:id:suzusin:20181117200332p:plain

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

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

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

続きを読む

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を使って開発する
    • 次に既存のモノリスAPIapi 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
  • 小さいスコープで行う
  • 小さい成功か失敗を繰り返すことでノウハウを蓄積

移行順の決め方

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

最高の開発に向けて

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

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

接続に成功!

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

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"

コンテナを立ち上げ直すと、ちゃんと変更されていることが確認できました。

f:id:suzusin:20180606000431p:plain

PHPerKaigi 2018に参加してきた

blogめちゃサボってたんですが、来年以降の開催のためにシェアーして!という話もあり、良い機会なので!

タイトルどおり、ことしから始まったPHPerKaigi 2018に参加してきました。

f:id:suzusin:20180311125150j:plain

確か昨年10月のPHP勉強会に参加したときに開催の話を聞いて、スポンサー募集と併せて社内で話はしたものの当時は時期も悪く。 その後、時は流れて@m_norii さんが話を通してくれたので、自分も気になって参加してきました。

感想としては、やはり界隈のトップを走っている方たちは凄い。 知識、トーク力、掛け合い? ノリと勢い…お祭り感も。 前職では.NET界隈でしたが、結構カルチャーの違いを感じました。

あとはセッションの難易度も結構感じられて、 移民の駆け出しPHPer的には、「なるほど!」だったり「なるほど、わからん」だったり。 MSのイベントとかだとセッションレベルが設けられていますが、将来的にはそうなってくれると嬉しいかなーとか。 もちろん本当は全部予習して臨むのが望ましいんですが。

そんな理由もあって、ベストトークは @hidenorigoto さんの『SOLIDの原則って、どんなふうに使うの?』に投票しました。 他の方もとてもレベルが高かったですが、納得のベストトーク賞だと思いました!

スライドリンク、ありがとうございます。 www.manasnote.com

f:id:suzusin:20180311125153j:plain もはやビール祭りでしたが、ちょうど薬を飲んでてノンアルDayだったので、CAさんの無限コーヒーが有難かった!

f:id:suzusin:20180311125139j:plain Job Board、なぜ弊社はないのか。

phpカンファレンス2017に参加してきた

f:id:suzusin:20171008173133j:plain

初参加でした。 小並感の走り書きです。

セッションについて

  1. ネームバリューは気にしない。知らない会社さんでも良いセッションはたくさんある
  2. スポンサーセッションは宣伝・紹介的な内容が入るので、自社と事業内容が被らないと得るものが少ない
  3. デモセッションは扱う技術の素人が行くと置いてけぼりのリスクがある
  4. それでも大体の資料は後から公開されるので、デモセッションに行くべきか
  5. 知らないツールや技術でも事前に概要抑えてからいくと聞いてる時に余裕が出来て良い

その他

  • プランニングポーカーもらったの地味に嬉しい
  • 全スライド撮影ニキやキーボード強打ネキが近くにいるときは席移動したくなった