Kotlinで公開鍵暗号方式の鍵を扱うときの備忘録とかJWTの生成とか

目的

KotlinでJWTを生成したい。

実際はKtorでサーバー書いてJWT返す処理を書いたけど、そこは割愛。

準備

opensslで秘密鍵の生成。

$ openssl genrsa -out private.key 2048

JavaのPKCS8EncodedKeySpecで秘密鍵のインスタンスを作るのに秘密鍵を PKCS 8 形式にしておく。

$ openssl pkcs8 -in private.key -topk8 -nocrypt -out private.key.pk8

公開鍵は特別なことはせず作成。

$ openssl rsa -in private.key -pubout -out public.key

鍵、どうやって扱おう

鍵ファイルをそのまま扱うのは正直面倒なので、環境変数に格納して扱いたい。

ただ、ファイルの内容をそのまま環境変数に入れようとしても改行が入っているのでそのまま扱うのは避けたい。

扱えないわけではないけど、改行コードの扱いだったりDotenvのアレコレでハマるのも嫌なので改行なしの文字列として扱えるようにしてしまう。

以下のような感じでソイヤっとBase64エンコードしちゃう。で、それを環境変数だったり.envに設定する。

そもそも鍵の中身自体Base64エンコードされていてマトリョーシカ感あるけどソレはソレ。

$ base64 -i private.key.pk8
$ base64 -i public.key

作った鍵を使ってJWTを生成する

JWTの生成は以下を利用。

鍵の文字列からそれぞれのKeySpecをつくるところは、そのまま以下のブログを参考にした。

PemReader.readFirstSectionAndClose を使いたいがために以下を入れてしまっているので、気になる人は自分で書いても良いと思う。

    private val dotenv = dotenv { ignoreIfMissing = true }
    private val privateKeyString = Base64.getDecoder().decode(dotenv.get("RSA_PRIVATE_KEY")).decodeToString()
    private val publicKeyString = Base64.getDecoder().decode(dotenv.get("RSA_PUBLIC_KEY")).decodeToString()

    private val keyFactory: KeyFactory = KeyFactory.getInstance("RSA")
    private val privateKey = keyFactory.generatePrivate(privateKeyString.fromPKCS8toKeySpec()) as RSAPrivateKey
    private val publicKey = keyFactory.generatePublic(publicKeyString.fromX509toKeySpec()) as RSAPublicKey
     private val algorithm: Algorithm = Algorithm.RSA256(publicKey, privateKey)

    fun create(contract: PostContract): String {
        return JWT.create()
            .withIssuer("hogehoge")
            .withExpiresAt(Date.from(ZonedDateTime.now(ZoneOffset.UTC).plusDays(1L).toInstant()))
            .withIssuedAt(Date.from(ZonedDateTime.now(ZoneOffset.UTC).toInstant()))
            .sign(algorithm)
    }

    private fun String.fromPKCS8toKeySpec(): PKCS8EncodedKeySpec {
        return PKCS8EncodedKeySpec(PemReader.readFirstSectionAndClose(StringReader(this)).base64DecodedBytes)
    }

    private fun String.fromX509toKeySpec(): X509EncodedKeySpec {
        return X509EncodedKeySpec(PemReader.readFirstSectionAndClose(StringReader(this)).base64DecodedBytes)
    }

DevLOVEとじぶんの10年、これからの10年

6/22, 23にDevLOVE Xに参加してきました。

devlove.wixsite.com

まずは、運営のみなさん、会場を提供してくれたNAVITIMEさん、ありがとうございました。

今年度から役職になったこともあり、マネジメントや組織の話し8割、技術系の話し2割くらいの割合で聴講しました。

メモをいっぱい書いたものの、ほとんど資料は公開されているので、じぶんの10年を振り返ってみようかなと思います。（メモは消しちゃった）

f:id:tenten0213:20190624151900p:plain
めも

なので、以下はポエム。

これまでの10年

新卒で現在の会社に入社して丸10年。現在11年目なので、DevLOVEと同期ですね！ DevLOVEは、私が現在所属している会社の社内イベントが開始のキッカケだと聞いています。"聞いています"という表現をするのは、参加したことがなかったから。

10年前の私は情報感度が低く、社内のイベントの存在をしりませんでした。そもそも、イベントのことを知っていても参加しなかったように思います。

私は入社後、クレジットカードの基幹系システム（会員管理とかカード発行とか）の保守開発を2年半ほどやっていました。 その後、同様にクレジットカード基幹系システムの大規模リプレース案件に連続して参画しました。確か、2011年のことだったと思います。1件目の大規模開発では20人ほどいるチームのテックリードとして横断的に必要な処理の開発や、構成管理(当時はSubversionでしたね…）、CI環境の構築、Redmineを利用したチケット駆動開発の導入なんかをしました。

ここで、どうRedmineを使っていくのが良いかを @yohhatu さんに相談したことからコミュニティというものに少しづつ関わるようになります。

yohhatuさんに誘われ社内のRedmine勉強会で発表したのが、初めて勉強会というものに参加した経験だったように思います。 ここらへんの時期にアジャイルというものに出会い、社内で開催されていたアジャイルサムライ読書会に参加しています(しかも最終回…！）

その後も継続して、大阪と東京をテレビ会議でつないで何冊か読書会を継続しました。何読んだかな？もう一周アジャイルサムライとか、レガシーコード改善ガイドとか。

今でも覚えているのは、レガシーコード改善ガイドを大阪の同僚と読んでいるときに、お互いの状況をどう変えられるか？みたいな話しをしたのですが、彼が保守しているシステムで使っている言語がRPGという言語で、自動テスト…無理だよねぇ…と無力感を感じたのを覚えています。

当時は彼と自分は全然別の所属だったのですが、現在は同じ部門で働いており、バリバリScalaやAkkaを使っているのでわからないものです。

大体時を同じくして、yohhatuさんと同様に私のエンジニア人生に大きな影響を与える@kawasima さんと出会います。 確か、社内のアーキテクトを集めてイベントをやろうということで、私は若手枠で呼んでもらいました。

当時SIerオワコン説の全盛期で、自身のキャリアに悩んでいる時期でもありました。（今でも悩んでいますけどね！） DevLOVE Xの倉貫さんの セッション でもあった通り、マネジメントの会社、マネジメント偏重の時期で、先輩、上司の仕事っぷりを見ても全然楽しそうに思えませんでした。

そんななか、kawasimaさんはニコニコ本当に楽しそうに社内システムをHackする話し（FelicaポートでSuicaを読み取って自動で経費精算する仕組みとか）や、kawasima/virn: vim clone (U.S.O) など作ったOSSの話しをしていました。(あれ？Emacs派だよな…)

その姿がモヤモヤしていた自分にとって新鮮で、衝撃的で…
これが自分にとっての「脳のブレーキを壊す」出会いだったのだろうと思います。

そこから家で勉強したりコードを書いたりするようになりましたし、社内でRubyの勉強会を開いたりもしました。 社外だと、DevLOVEやアジャイル界隈のコミュニティによく参加していました。

しかし、仕事面は思ったようにいっておらず、それこそAgile or dieみたいな…。

https://image.slidesharecdn.com/itsyagniorstopthinking-190622082007/95/yagni-2-638.jpg?cb=1561195260

コミュニティに参加したり、本で読んで勉強をしたアジャイル開発、スクラムをやりたい！けど会社が、組織が、お客さんが、色々不満を溜め、グチグチ言っていた時期でした。

外の世界と自社とのギャップに苦しんだり、子供が生まれたということもあり、外部のコミュニティ（特にアジャイルやスクラム）や勉強会から距離を置くようになります。…Java界隈には顔を出していた気がするな？？

社内では勉強会？を継続的にやっていて、毎週金曜日の朝7:30からスターバックスで本を読んだりコードを書いたりしていました。 @_siosioさん、@syobochim、@uggdsと一緒にやっていたけど、syobochimはしょっちゅう寝坊して居なかったなーｗ

しおしおさんからはIntelliJ IDEAの使い方教わったり、プロジェクトの課題の相談に乗ってもらったり…本当に勉強になりました。しおしおさんはソフトウェアエンジニアとしてのメンターというか、師匠というかそんな感じですね。

そこからいくつか開発プロジェクトを経験し、2016年頃に日本初のペイメントサービスの開発に参画しました。これがまあ大変で、炎上したり衝突したりしながら過ごしてきました。

この時、かなりピリピリしながら、プレッシャーやストレスを感じながら仕事をしていたのですが、炎上の火消しで入ってくれたマネージャーに「俺は技術のことわからないけど、お前が技術力が高いのはわかる。お前を信頼して任せるから、大変だけど頑張ってくれ。責任は俺が取るから」的なこと（ニュアンスは違うかも）を言われて、一気に課題に集中できるようになりました。これがマネジメントだなーと思った原体験ですかね。

この上司とはその後もいくつか一緒に仕事をし、今もちょくちょく一緒にランチに行って雑談をする仲です。こういう存在は本当にありがたいです。

Iさん見てるー？＼(^o^)／

ちなみにこのシステムは、多くの同僚に助けられて無事リリースし、大きな障害もなく今日まで来ています。たぶん。

その後、社内もお客さんもアジャイル開発やろうという機運が高まってきたようで、iOSアプリ開発やったりスクラムマスターやったり、E2Eのテスト導入支援したり、スクラムの導入支援やったり…色々やってきました。

そういえば、認定スクラムマスターの研修を会社に費用を出してもらって受けさせてもらったのもこの時期ですね。江端さんの研修も頭ぶん殴られる感じがあって最高だったなー。

去年、今年は全社、グループ会社全体のサービス開発がうまく行くようにすべく、施策を企画、提案し、計画、推進したりしてきました。 上司にも恵まれて、エンジニアとしてもマネージャーとしても、人間としても尊敬できるボスの下で働けています。

視座を上げろ視座を上げろと他人から言われるのは好きじゃないのですが、視座が上がったなーと思う2年間でした。

個人的には、視座を上げるだけでなく下げたり（何なら左右にも）、解像度を上げたり下げたりできるのが良いなと思っています。

10年…色々ありましたが、振り返ってみると人に恵まれた10年間でした。 これはこの会社じゃないと得られなかった財産だと思うので、本当に良い会社に入社したと思っています。

これからの10年

役職に上がって間もないので、まだモヤモヤしている部分が正直あったりします。 コードをまだまだ書きたい気持ちもありつつ（最近全然書いていない）、マネジメントにも興味あるし。組織マネジメントにも興味が出てきたりもしているし。 いわゆる管理、みたいな誰がやっても同じような仕事はしたくないので、そこは意識しつつ仕事をしていこうかなと思っています。

10年…長いので、ソフトウェアエンジニア、デザイナー、マーケター、営業…全員がお互いをリスペクトしあい、楽しく、学習しながらお金を稼げる、貰えるような組織とか作れたら良いなーなんて思っています。

この10年の間にマネージャー、エンジニアの両方を行ったり来たり、別のことやったりできたら面白いかなー。

まあ10年長いですからね。

10年前に現在の自分を想像できていなかったし、この先10年もどうせ想像していなかった場所に向かうだろうから、その時々で向き合っていくしかないかなと思っています。

2日目、途中のワークで書いたこれまでの10年とこれからの10年↓

f:id:tenten0213:20190624225106j:plain

DevLOVE X

自社の若手が何人か（こういった勉強会に来るの初めてって人が大半）来ていたので、OBだったり知人を紹介したりしました。お話しをしてくれたみなさん、ありがとうございました！

セッションは楽しめたかな？何かを持って帰れたかな？何か持って帰れていたら良いなー

久々のDevLOVEだったので、久々の人と話したりできて楽しかったです。自分が3、4年目の時に知り合った人も結構いて、その時からの自身の成長を実感できたのがとても良かったです。

DevLOVEに来ると色々な人と話したりできるので、話すことで自分の本心だったり考えが整理されますね。

昔は会社のこととか組織に対して不満だったり愚痴が多かったけど、今回は素直に「仕事楽しいですか？」という問いに「楽しいです！」と返せました。 これが個人的に凄い良かったです。

10年かけて信頼貯金を得て、裁量が与えられるようになって、自分で仕事をドライブしているから「楽しい」と言える部分もあると思っていますが、組織の雰囲気だったり、会社の制度だったりも良くなってきているので、素直にお薦めできる会社になってきました。

OBである倉貫さんにも伝えられて嬉しかった。

…最近採用に関わっていまして、興味がある方はご連絡いただければと…！！！！

最後は宣伝でおわり。

久々のDevLOVE最高でした！！！！！！！！！！！！！

役職になった

2019年4月より昇格して、役職になりました。 …役職ってなんだ？

特に管理職のことを指す

なるほど？

ちなみに、役職になっても特にやることは変わらない…と思う。 勤怠管理とか予算の管理とか、メンバーの評価とか追加になる感じ。
一応権限とかは増えているはず。

一応役職なので残業代がでなくなる。
その代わり？裁量労働制になる。基本給がガッと上がったヽ(=´▽`=)ﾉ
もともとコアタイム無しのフレックスだったので、働き方はあまり変わらなそう。

課長とかそういったものではないので、明確に部下ってものが存在するわけでもない。
というか、同じ役職と2人で仕事している。

そんな感じだけど、楽しく働ける組織にしたいし、成長できる組織にしたいし、ちゃんと会社に貢献している組織にしていきたい。
色々がんばっていくぞ〜

以下を読んで良いなと思ったので書こうとしているけど、なかなか書き終わらない。
頑張って書く…書くったら書く。

昇格祝いに後輩(元)から本をもらった。
嬉しくて泣きかけた。

よく出来た後輩に恥じないよう精進しよう。 本読んで勉強します。

f:id:tenten0213:20190411214354j:plain
昇格祝に後輩からもらった本

成人発達理論による能力の成長 ダイナミックスキル理論の実践的活用法

成人発達理論による能力の成長 ダイナミックスキル理論の実践的活用法

「いちばんやさしいGit&GitHubの教本」はタイトル通りやさしさに溢れていた

book.impress.co.jp

宇賀神さん、横田さん、ご出版おめでとうございます！

元同僚である宇賀神さん(@syobochim) から頂いたので、読んだ感想を書こうと思います。

感想

タイトルに いちばんやさしい 、表紙に はじめてでも、挫折しません。 と書かれているのですが、言葉の通り、 かな 〜〜〜りやさしく 書かれています。

目次は以下の通りで、Gitがどういったものなのか、なぜ必要なのかから始まり、Gitのインストール、基本的な操作、GitHubを使った共同作業のやりかたまで書かれています。私自身は普段からGitを利用しているため、サクサク読み進めて4時間ほどで読み終えました。Gitを初めて使うという人が操作しながら読み進めても、恐らく2日はかからないで開発に参加できるようになるかな、といったボリューム感です。

  • Chapter 1 Gitの基本を学ぼう
  • Chapter 2 Gitを使う準備をしよう
  • Chapter 3 ファイルをバージョン管理してみよう
  • Chapter 4 GitHubのリポジトリをパソコンに取得しよう
  • Chapter 5 ブランチを使ってファイルを更新しよう
  • Chapter 6 複数ブランチを同時に使ってファイルを作業しよう
  • Chapter 7 コンフリクトに対処しよう
  • Chapter 8 GitHubをさらに使いこなそう

どう"やさしい" のか

全体を通して、キャプチャや図が多く使われています。Git…というかDVCSは特有のとっつきにくさがあるように思うのですが、図を使うことで、とてもわかりやすく伝えています。以下のリンクから試し読みができるので、どんな感じか気になる方は読んでみると良いと思います。

本文では基本的にCUIによる操作で学ぶことを推奨しているのですが、どうしても馴染めない人に対してGUIの利用についてもフォローしています。 個人的に良いなと思ったのが 大切なのはツールではなく、Gitで何ができるのかを理解し、実際にバージョン管理ができる状態になることです。 (p.66) の一文です。Gitもツールだろというツッコミはおいておいて、本質的に大切な点、学んでほしい点が表れているように感じました。

CUIに関しては、 pwd や mkdir など基本的なコマンドまで丁寧に説明してあり、挫折のしようが無い感じです。 逆に、普段ソフトウェア開発などを行っている人にとっては冗長に感じるかもしれません。

その他、読み進めていくと人気講師(！！)のお二人に褒められる？タイミングがあり、成長を感じられる点も良いなと思いました。 (省略)… 少しずつ、でも着実に、できることが増えていますね！ など。

焦点を絞って実践的な内容をコンパクトにまとめている

これは個人的に感じたことなのですが、あえて内容をかなり絞っているように思いました。本で紹介されているコマンドには、tagの作成や、revert, rebase(GitHubのマージのオプションで軽く触れている程度)、stashなどは含まれていません。その代わり、基本的な内容を丁寧に、230ページ程のボリューム(しかも図やキャプチャがかなり多め)で理解できるようにまとまっています。

一言で表すと、ソフトウェア開発に必要となるGitの基本的な操作・知識をコンパクトに、丁寧に説明している本 かなと思います。

Gitを利用した開発をしたことが無い人や、新人研修などに適しているように感じました。 また、雰囲気だけ理解してGitを利用してきた人にとっても、理解を深められる良い本だと思います。

まずは いちばんやさしいGit&GitHubの教本 を読み、Pro Git や他のGitの本で更に深く学ぶのが良さそうです。

少し気になった点

Lesson 21 Gitで管理しないファイルを設定しましょう で .gitignoreファイルはローカルリポジトリ配下であればどこに置いてもいいですが、.gitignoreファイルが配置されたディレクトリ配下のパスにしか効果がありません。 (p.104) と書かれていますが、以下のようにユーザーのホームディレクトリに配置すると、どのローカルリポジトリ配下でも有効に動作します。以下では .gitignore_global というファイルを作っているので .gitignore_global の方が良いのかもしれませんが…

$ cat ~/.gitignore
*.swp
*.swo
*.vim
.idea
.iml
files.list
tags
.netrwhist
*.log
.DS_STORE
node_modules

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

$ touch hoge.log
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

しょぼちむとの思い出

しょぼちむとは、2015年の今頃の季節に同じプロジェクトで働いていました。

そのプロジェクトは決済サービスの開発プロジェクトで、私としょぼちむはアプリケーションの基盤チームのような部隊に所属していました。

アプリケーションを主に開発する部隊は今までSubversionをずっと利用してきており、クレジットカードの基幹システムなどの固い領域をずっと担当してきた人たちでした。当然Gitを利用したことがある人など皆無です。そして、20人以上いる開発者が一斉に開発をスタートしなければいけないような状態でした。

しかし、プロジェクトのコンテキストとして、

  • 同時に開発が進む接続先
  • 数多く入るであろう仕様変更
  • 並行して進む目的の異なるテスト

などなどの要因があり、柔軟な構成管理が必要だと判断し、思い切ってGitを採用しました。

当然初めてGitを使う人が20人もいるので導入は容易では無いのですが、しょぼちむが丁寧なガイドを作ってくれたおかげで大した混乱もなく開発を進めることができました。

プロジェクトの状況に合わせ、どうブランチを作るか、ライブラリのバージョニングをどうするか、一緒に考えて説明したのは良い思い出です。

当時書いた資料、どう書いたら彼らに理解してもらえるか、いろいろ悩みながら作ったんだと思います。 今回出版された本を読み、当時似たような図を書いていたなーと思い出したりしました。

あの時の経験が今に活かされているのだろうなと、感慨深く読ませていただきました。

……

これであの資料を封印できる！！

いちばんやさしいGit&GitHubの教本 を渡せばそれで済むのでは！！？？

もう「Gitわかりません」なんて言わせないぞ٩(๑`^´๑)۶

良い本を書いてくれてありがとー！！

シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1 on1ミーティング を読んだ

これです。

シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1 on1ミーティング―

シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1 on1ミーティング―

最近、チームのマネジメントを行っています。
何年か前からメンターや上司と1 on 1をしていたものの、受ける側した経験がなかったので体系的に学ぶために読んでみました。

1 on 1は個人に焦点を当てた対話

普段プロジェクトを通して働いていると、問題解決のための打ち合わせやチームとしての対話がメインとなり、個人との対話は日常的な雑談くらいしかありません。
1 on 1では、必然的に1 対 1になるので、個人に焦点を当てた対話になります。

1 on 1によってプライベートの理解、心身の状態の把握、モチベーションアップなどを通して信頼関係を築くことができます。 また、成長の支援を行う場にもなります。

1 on 1でなにを話すのか？

本では、部下との関係(ステージ)や状況によって話すテーマを変えることが書かれています。 プロジェクトの開始時や半期の目標設定時、評価時などでしか話せていないなと思う項目も多く、意識していきたいと思いました。

信頼関係づくりステージ

  • プライベート相互理解
  • 心身の健康チェック
  • モチベーションアップ

成長支援ステージ

  • 業務・組織課題の改善
  • 目標設定 / 評価
  • 能力開発 / キャリア支援
  • 戦略・方針の伝達

具体的な進め方

  • 実施する目的や内容を合意する
  • スケジューリングする
    • 定例化 しない
      • 定例になると"いつもと同じ"とおざなりになりがち(定期的に行うのは大事)
      • イベントとして捉える
  • 場所を決める
    • いつも同じ場所じゃなくても良い
    • 近くのカフェとかでも良いかも？
  • 準備する
    • お菓子などあるとリラックスする
    • 付箋やペン
    • アジェンダと時間割
    • 前回の1 on 1のメモ

継続することが大事

忙しい、面倒、など理由はいくらでもありますが、続けることが大事だと書かれています。 半年くらいはムズムズする(？)ようなことが書かれていたので、まずは継続していこうと思います。

本を読んでやりたいと思ったこと

本ではEvernoteを使ってメモを残すようなことが書かれていましたが、自分なりに使いやすいフォーマットやツールを模索したいと思いました。

チームの異動はそれなりにあるのですが、1 on 1の記録が残っていれば様々な面の引き継ぎにも有用そうです。

まとめ

本書には "なぜ1 on 1が大事なのか"、"1 on 1で何を話すのか"、"1 on 1をどう進めるのか"が平易な言葉でわかりやすく書かれていました。 はじめて 1 on 1を実施する人にはおすすめできる一冊だと思います。

AWS LambdaのCOBOLサポートについて少し調べてみた

AWS re:Invent 2018で、LambdaでRubyを使えるようになったと発表がありました。 合わせて、カスタムランタイムとしてあらゆるプログラム言語を利用できるようになるようです。

また、ErlangやPHP 、COBOLのランタイムがパートナーにより提供されることも発表されています。

…そう、COBOLです。

需要あるのか？いや、面白いかも？どうだろう…

SIerとしてはどうしても気になるCOBOL。

新卒で金融系の部門に配属され、新人研修で学んだCOBOL。3年目くらいまでは書いていたCOBOL。

どこがパートナーとしてランタイムを提供して、どんな狙いがあるのか気になったので発表されていた会社を調べてみました。

COBOLのランタイムは Blu Age という会社が提供するようです。

どんな会社なのかな？と見てみると、メインフレーム上で動いているCOBOLやPL / I、RPGなどで書かれたレガシーアプリケーションをマイグレーションだったり近代化するのが得意な会社のようです。

AWS LambdaでのCOBOLサポートについては、以下に狙いやアーキテクチャについての説明が書かれています。

狙いとしては、メインフレーム上で動かしているCOBOLを書き換えることなくサーバレスアーキテクチャに移行することができる。これにより運用コストが大幅に削減できる…と。確かにメインフレームの維持費用がなくなれば大幅にコスト減できそうです。実際に移行するにはもっと複雑ではあると思いますが、それはそれとして。

どうやって動かすのかというと、発表されたAWS Lambda Layers機能を活用し、Java 8 ランタイムの上にCOBOLを実行するためのランタイムライブラリを提供する、とのこと。

…ん？これ、COBOLをコンパイルしてJVM上で動くようにしているか、COBOL→Javaにしてから実行可能な形にしているか、では？

だとすると、初回起動が遅いとかメモリ使用量が多いとかJavaと同じ傾向が出るのでしょうか。 使えるようになったら試してみたいですね。

Spring Fest 2018に参加してきました

Spring Fest 2018 に参加してきました。

参加したセッションは以下の通りです。
キーノートが結構盛り上がっていたのですが、子供を保育園に送ってから行ったら間に合わず…

  • 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  • 実際のプロジェクトでSpringアプリをKotlinで開発して得た気づき集
  • Knative: Serving your Serverless Java Service on Kubernetes the 12-Factor way
  • 500+のサーバーで動くLINE Ads PlatformをささえるSpring
  • Spring Boot with Kotlin, functional configuration and GraalVM
  • Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜

それぞれ聴講した感想を。

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

自身のキャリアとして、クレジットカードの基幹システムや決済システムに多く携わってきたのでとても興味があったセッションです。

内容としては、開発をベンダーに任せきりだった状態から、

  • 運用作業の自動化
  • 開発基盤の整備(GitHub Enterprise、Slack、Confluence、Jiraの導入)
  • サービス監視の導入(Elastic Stack)
  • CIの導入(Jenkins, Nexus, SonarQube)
  • Spring Boot、Spring Cloudへ

と身近なできるところから進め、体制を増やしながら改善を進めてきたという前振りから始まりました。 正直、ここまでで十分すごいなって感じだったのですが、その後プラットフォームとして Pivotal Application Service（PAS） を採用、Concourse CI でビルドパイプラインの構築、開発環境では常にCI/CDが実行され、Productionへはワンクリックでデプロイされるというモダンな構成まで持っていっていて凄いですね…。ベンダーに任せきりから2,3年でここまで来るって思うと、エンダー(SIer)側の立場から見て色々思うところがありました。

資料でわかりやすかったのは、開発プロジェクトの体制と責任分界って箇所。アプリケーション開発者はアプリケーションとデータまで、The Twelve-Factor Appを守ること、ってところが明快で理解しやすかったです。

そのほか、

  • Javaの複数バージョンでCIを実施している
    • バージョンアップ前から実施しているので、バージョンアップする際に安心してあげられる(なるほど！)
    • 本番のJavaバージョン以外でCIが失敗していても本番のバージョンのCIが通っていればOKとした場合、いつコケた箇所を直すんだろう？(すぐに、だと思うけど優先順位が低くなりがちになりそうに思えて、放置されないのかなーとか)
    • Javaのバージョンアップについていく姿勢良い。 攻めて守る ！！
  • JMeterでの性能テストを毎日継続して実行、Slackにレポートを送るの良い
    • AWSなどを使うと難しそう(コスト面や申請などで)
  • アプリケーション構成の章のわかりみが凄かった
    • 他加盟店に影響がでないように作り込んだことあるなーとか
    • 接続先多いと大変だよねーとか
    • 決済機関とか特殊な プロトコルでやりとりしたり、色々面倒や苦労があると思うんだけど、そこらへんも聞きたかった。懇親会出ればよかったー

などなど色々感想が出てきて、とても楽しかったです！ まだ新システムをリリースしていないとのことだったので、リリース後にどうなったか聞いてみたいと思いました。

実際のプロジェクトでSpringアプリをKotlinで開発して得た気づき集

最近AndroidアプリをKotlinで書いてたりするので(めっちゃ初心者)、興味のあったKotlinのセッションへ。

セッションは、SpringとKotlinの関係(仲良し！)からKotlinのおさらいとSpring利用時の注意点、Spring WebFluxとCoroutinesあたりの話し、Springのアノテーションを減らす、Kotlinでのテスト、といった内容でした。

SpringをKotlinで利用する場合の注意点などは、初心者な自分にもわかりやすく、とてもありがたかったです。

Spring WebFluxでCoroutinesを使う話しあたりはじっくり資料読んだりドキュメント読まないと自分には厳しいですね(´・ω・`) ただ、KotlinのCoroutinesを利用するとスッキリして読みやすく、書きやすくなることは分かったので機会があった際の選択肢にはなるかなと思います。 仕事上、ここらへんの技術を使う機会があるのか怪しいですが…

アノテーションを消していくってところは、いまいちモチベーションが分からなかったですが、起動速度が早くなるのは良いなと思いました。

テストについてはJUnit5を利用しており、モックはMockKを利用している。 特定の文脈でしか呼び出せないCoroutineの呼び出しだったり、デフォルト finalになるクラスもモックにできるのでMockKは便利(というかこれ以外良い選択肢がなさそう？)。

コーディングは ktlint: An anti-bikeshedding Kotlin linter with built-in formatter に従っており、それ以外についてはUbie社でKotlinのコーディングスタイルガイドを作成し、それに従っているとのこと。あ、lateinitとか普通に使ってたな…

Knative: Serving your Serverless Java Service on Kubernetes the 12-Factor way

Knativeの話しが聞きたくて行ったのですが、ほとんど無くて残念でした。 しかも、前半の前振りで疲れて肝心のKnativeの説明部分を集中して聞けず…

ServerlessやFaaSの説明はほどほどに、Knativeの話しをもっとしてほしかった…

500+のサーバーで動くLINE Ads PlatformをささえるSpring

LINEの広告プラットフォームの話。 LINEの広告は7800万人(MAU) にリーチできる(凄い…)プラットフォーム。広告は様々なバリエーション、レイアウト、フォーマットで出す必要があり、しかも50ms以内にオークションしてレスポンスを返さなければならない厳しいシステムとのこと。

広告系の単語が多く、理解しづらい点もありましたが、そこそこ面倒なことを爆速でやらなければならない大変さが滲み出ていました。

アーキテクチャ周りは、基本的にはメモリに乗るものは乗せる、ダメならRedis、みたいな感じで速度をかなり意識している感じです。 サービス間の連携はKafkaを使っていて、かなり使い倒しているようです。

GCが気になるからGoにしたって話しと、ヒープを増やして対応したって話しがあって、Goにせずともどうにかなったのでは？とか思いました。 ちなみに、G1GCを選択していたようですが、ヒープ増やす前の4Gは少ないんじゃないかな？と思いました。

Spring Boot with Kotlin, functional configuration and GraalVM

甲府ー、じゃふー。 Spring Bootでアノテーションで設定しているところを関数(lambda)で設定する、設定はKofu, JafuというDSLで記載する…って感じ？

翻訳するとヤバイ

f:id:tenten0213:20181105221735p:plain

たろうさんのセッションでもあったように、クラスパススキャンが無くなるので起動速度が早くなるという点と、メモリ消費量が少なくなる、GraalVMネイティブイメージフレンドリーといった特徴があるようです。

キーノートでデモしたのかな？相当起動速度が早いようなので、コンテナだったりFaaSの領域で活きてくると面白いなーと思いました。 普段の開発時はさすがにネイティブイメージをビルドじゃなく、ふつうにサーバ立ち上げるのかな？開発、デプロイのプロセスってどうなるんだろう？

Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜

MicrometerとPrometheusを使って、3000以上のSpringアプリ、数先インスタンスの監視を行っているとのこと。 プラットフォームは多様で、OpenStack、k8s、PCFなどを利用している。処理の方式も、Web、Web API、バッチ、Pub/Subなど様々。

その監視・運用で困ったことや工夫したことなどを語っていました。 具体的なハマりポイントと、どう解決したかが語られていて、Micrometer, Prometheusを利用している人には参考になりそうでした。 メモはしてあるのですが、合っているか不安なので…資料公開されるのを期待しています！

おわりに

各社の事例と、尖った技術の話しを中心に聞きました。 事例は凄いなって思うものや、参考になるものが多く勉強になりました。尖った技術の話は理解できない箇所も多かったですが、来年、再来年あたりどう変わっているかな？と考えると面白かったです。

運営をしてくださったみなさん、JSUGのみなさん、ありがとうございました！！