#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
実録Blue-Green Deployment導入記
2016/12/3 JJUG CCC 2016 Fall
大中浩行
この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
注意！
このセッションでは、以下の様なイカしたキー
ワードは出てきません！
• Infrastructure as Code
• Docker
• Serverless Architecture

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
今日お話すること
一つの組織の中でメンテナンスするアプリケー
ションを分割して開発・運用する時に、
• システム同士をどう連携させるか
• 稼働する系統(Blue/Green)の切替えをどう
行うか

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
お品書き
• Blue-Green Deploymentとは
• Blue-Green Deployment導入の障壁
• GSLB
• データベース
• Blue-Green

#ccc_g11
Copyright 2016 Hiroyuki Onaka
Blue-Green
Deploymentとは

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「継続的デリバリー」
「本番環境としてまったく同じ環境を2組用意す
るという考え方で、それぞれをブルーおよびグ
リーンと呼ぶ。」
Jez Hunble, David Farley(著) 和智右桂、髙木正広(訳)
「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
クラウド時代のBlue-Green Deployment
「Deep Dive into Blue/Green Deployments on AWS」
http://www.slideshare.net/AmazonWebServices/dvo401-deep-dive-into-bluegreen-deployments-on-aws

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Greenを実現する方法
• In Place: インスタンスはそのままに、新し
いリビジョンのアプリのみその場で反映され
る
• Blue/Green: 新しいリビジョンのアプリ用に、
新しいインスタンスを構築して入れ替える
AWS Solutions Architect ブログ: Blue/Greenデプロイとは？
http://aws.typepad.com/sajp/2015/12/what-is-blue-green-deployment.html

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• All at once: 全台を一斉に新しいリビジョン
でデプロイする
• One by one: 1台ずつ新しいリビジョンをデ
プロイする
• Batch: 数台(例えば半数)ずつ新しいリビ
ジョンをデプロイする

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
今日お話しするのは「In PlaceのBatch」の話に
なります。(アプリの入替を、半分のインスタン
スに対して行う)

#ccc_g11
Copyright 2016 Hiroyuki Onaka
サービスの紹
介

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
2014年秋のJJUG CCCで、TDD導入に
ついて発表しました
http://www.slideshare.net/setoazusa/jug-2014-fall-how-to-intoroduce-tdd

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
今日は、その続きの話です
その後どうなったか

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「TDDの導入したいんです」
→「CI導入しましょう」
→「デプロイ自動化したいですね」
→「インフラの自動化もお願いしたく」←ｲﾏｺｺ

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
インフラエンジニア爆誕
By Gsmith1of2 at English Wikipedia [Public domain], via Wikimedia Commons
https://commons.wikimedia.org/wiki/File%3ANetworkOperations.jpg

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
インフラエンジニアとは
• 開発チームの時…主にJava
• インフラチーム…主にシェルスクリプトと
ruby、たまにGo言語
• データセンターのラックの配線とか、しませ
んよ？

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• 通信事業者の法人向けサービス基盤
• 開発プロセスはスクラム
• 日本と海外拠点での並行開発(同一コード
ベース)
• サービスインして2年半

#ccc_g11
Copyright 2016 Hiroyuki Onaka
ロードバランサー
認可サーバー
Webサーバー&APIサーバー
データ連携サーバー
データベース
認証サーバー
AZ1 AZ2
Blueサーバー Greenサーバー

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
システムの構成
• ユーザー向け機能およびバックオフィスと、
ユーザーの認証およびシングルサインオンを
行うサーバー(認証サーバー)の二系統
• 認証サーバーはMulti-AZ(Availability Zone)
• 外部へのデータ連携はデータ連携サーバーが、
Spring Batchのジョブを随時起動する

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• サービスイン当初は、夜間の計画メンテナン
スによるリリース作業を行っていました

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• 夜間帯も含めて、ユーザーにリアルタイムに
通知を行う機能の追加
• 海外に拠点を持つユーザーが使用を開始
→夜間とはどこのTimeZoneの夜間なのか

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
そして何より、リリース時にサービス停止を伴
うことにより、頻繁なリリースによるフィード
バックを得ることが難しくなること。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ということで、Blue-Green
Deploymentに取り組むわけですが...
最初からBlue-Green Deploymentを想定して
開発できるなら、その方が絶対にいいです！
Blue-Green Deploymentの導入のために何回
夜勤をしたことか...(TT)

#ccc_g11
Copyright 2016 Hiroyuki Onaka
Blue-Green
導入の障壁
https://pixabay.com/ja/%E8%83%B8%E5%A3%81-%E5%A3%81-%E7%9F%B3%E5%A3%81-castelgrande-
%E3%83%99%E3%83%AA%E3%83%B3%E3%83%84%E3%82%A9%E3%83%BC%E3%83%8A-%E4%B8%AD%E4%B8%96-418950/

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「準備が整えば、新しいバージョンを公開する
のは単にルーターの設定を変えるだけの作業と
なる。これまでグリーン環境に向けていた設定
を、ブルー環境向けに切り替えればよいの
だ。」
「継続的デリバリー」から

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「切り替えればよいのだ」
By DanR
https://www.flickr.com/photos/dansdata/4083643660

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
最初は、こう

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「静的コンテンツのためにWebサーバー
いるよね」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「認可のこと考えるとリバースプロキシー
おいたほうが」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「データベースのこと忘れてました」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「外部のデータ連携は非同期で行いたい
んですよ」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「切替ポイントがいっぱいあるんですが…」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
Sam Newman(著) 佐藤直生(監訳)
「マイクロサービスアーキテクチャ」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
本来なら、独立したサービスがそれぞれ
ルーティングを切り替えればよい
BY Rose and Trev Clough(CC-BY SA 2.0) http://www.geograph.org.uk/photo/1490900

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
だが実際には、Blue/Greenのサーバ群の稼
働する系統を切り替えることになる

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
デプロイした後、サーバープロセスの起動だけ
確認してサービスインするつもりですか？
普通サービスインの前に動作確認ってするもの
じゃないんですか？

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
サービス特有の事情
「デプロイした後、本番環境上でシステムテス
トを行わないとサービスイン不可」という内部
ルール。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
結果として、この事例において「Blue-Green
Deploymentを導入する」ということは、「同
時に稼働するバージョンが違う本番環境が二つ
できる」ということになりました。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
このようなアプリケーション層の問題を乗り越
えたところで、Blue-Green Deploymentの実
現にはラスボスがいます

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1By NY
http://www.thebluediamondgallery.com/scrabble/d/database.html

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
データベースの手強さ
• Blue-Greenなのに環境間で共有している
• サービスインしたままでデータ構造の変更っ
てどうやるのさ？

#ccc_g11
Copyright 2016 Hiroyuki Onaka
冬の陣
(GSLB)
ムカイ(Public Domain) https://ja.wikipedia.org/wiki/%E5%A4%A7%E5%9D%82%E5%9F%8E

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
まず、ここの話
認証サーバー

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
認証サーバーは、それぞれのAZの稼働を交互に
切り替えてデプロイすることで、サービス無停
止でリリースが出来るようにします。
切替には、GSLBというアプライアンスを使いま
す。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLB
• 広域負荷分散(Global Site Load Balancing)
• DNSの応答を制御するタイプのロードバラン
サー

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLB
DNS制御

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLBを使えば、AZをまたいだサイト切
替が実現できます。
…カタログスペック上はね？

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
GSLBの運用で考慮が必要なもの
• DNSクライアントのキャッシュ
• クライアントのkeep-alive

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
WebブラウザーによるDNSキャッシュ
Ben Anderson 「Why Web Browser DNS Caching Can Be A Bad Thing」
http://dyn.com/blog/web-browser-dns-caching-bad-thing/

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Public CloudのDNSフェイルオーバーの検証記
事で、切替時にブラウザーを再起動しているも
のが散見されますが、これはブラウザーのプロ
セス上のDNSキャッシュが原因です。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
もう一つの問題
GSLB
DNS制御

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Javaプログラムから外部サーバーに接続する際、
JVM上のDNSキャッシュを無効にするために起
動オプションを付与する
(例: -Dsun.net.inetaddr.ttl=0
-Dsun.net.inetaddr.negative.ttl=1)
というノウハウがありますが、それだけでは不
十分なケースがあります。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
アプリケーショサーバー上でのkeep-alive接続
接続元のサーバーでkeep-aliveしている接続は、
DNSが切り替わってもそのまま使われます。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Green Deploymentを実現する上では、
DNSを切り替えてもクライアントの接続先サー
バーは切り替わらない。
というのが実態です。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
どうするか
GSLB
DNS制御

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
こうする
GSLB
DNS制御

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ロードバランサーでサーバーへの接続をTCPレ
ベルで切断すると、クライアントがそれをトリ
ガーにしてDNSのキャッシュを更新するので、
そうすると切替先のサーバーへ接続が向くよう
になります。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• ネットワーク構成や通信プロトコルによって、
実際の挙動はかわってきます。
• DNSを用いた負荷分散を行う場合は、切り替
え時の実機・実サーバー上の挙動について
しっかり検証を行いましょう。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
真田丸
(データベース)
By うぃき野郎 (Own work)
[CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons
https://commons.wikimedia.org/wiki/File:Restructured_Model_of_Sanadamaru_Fort1.jpg

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
基本的な考え
• データベースのスキーマーは、データベース
マイグレーションツールを使って、アプリ
ケーションのリリース時に更新する。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• 動作確認のために新バージョンのアプリケー
ションが作成したデータを旧バージョンのバッ
クオフィス機能で参照した時に、エラーが発生
しないようにする
• エンドユーザー向け機能はマルチテナントのアーキテ
クチャーになっているため新旧のデータが動作時に混
在することは少ないが、バックオフィス機能は全テナ
ントのデータを一括で扱うため

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
原則
• データ構造の互換性を失うようなマイグレー
ションは行わない
• データ構造を変更する場合は、新規カラムの
追加を最初のリリースで行い、その次のリ
リースで不要なカラムを削除する

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
で、うまくいくと思ったのですが...
• データ構造の変更を伴わないマスターデータ
の更新(仕様変更)を行った際に、切り替え元
(旧バージョン)の動作で支障を来すケースが
発生。
• 具体的にはURLに対するアクセス認可のマス
ター

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
解決策
• 主系(旧バージョン)と副系(新バージョン)で
仕様が変わることがあり得るマスターに対し
てはデータベースで保持するのをやめて、ア
プリケーション側で設定ファイルとして保持
するようにする

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「マイクロサービスアーキテクチャ」から
「第2の選択肢は、代わりにこの共有静的データ
をコードとして扱うことです。...データの一貫
性に関する問題は残りますが、経験から、稼働
中のデータベーステーブルを変更するよりも変
更を構成ファイルに展開する方がはるかに簡単
であることがわかります。」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
By Snlf1 (Own work)
[CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Akazonae_Sanada.jpg
夏の陣
(Blue-Green)

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• ロードバランサーのルーティング
• 非同期処理の連携
• Blue-Greenの切替

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
その前に、私達のドメインの用語の確認
をさせてください
• 主系…Blueサーバー/Greenサーバーの内、サービス
インしている系統。本番環境。切替後は副系になる。
• 副系…もう一方の、新しいバージョンをデプロイし
て、動作確認を行っている系統。切替後は主系にな
る。
「Blueが主系、Greenが副系」という言い方をします。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ロードバランサーのルーティング
• ユーザーからのアクセスは主系に、動作確認
のためのアクセスは副系に振り分ける

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
グローバル
IPアドレス1
(主系用)
グローバルIP
アドレス2
(副系用)
Blueサーバー ○ ×
Greenサーバー × ○

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
グローバル
IPアドレス1
(主系用)
グローバルIP
アドレス2
(副系用)
Blueサーバー × ○
Greenサーバー ○ ×

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
非同期処理の連携
アクセスが来た後、データ連携を行うまでの、サー
バー間のトランザクションは、主系サーバー、副系
サーバー相互で連動して動くようにする
Blueサーバーが主系の時、主系(Blueサーバー)が登
録したデータは、同じく主系(Blueサーバー)のデー
タ連携サーバーが処理する

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ここが問題
※非同期

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
対処法
• BlueサーバーとGreenサーバーどちらが主系でどち
らが副系かをデータベース上に保持し、参照する。
• O/Rマッパー(Hibernate)上の処理にinterceptorを
適用して、データベース上に投入するレコードが、
主系が投入したレコードなのか、副系で投入したレ
コードなのか、区別がつくようにする

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Greenの切替
主系、副系の切り替え時は、処理途中で主系
サーバーがBlue(Green)サーバーから
Green(Blue) サーバーに切り替わる場合がある
ので、それに対応できるようにする。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
切り替え手順を見てみましょう
以下は、
Blueサーバー主系、Greenサーバー副系
から、
Greenサーバー主系、Blueサーバー副系
に切り替える場合の手順

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
初期状態
GreenBlue

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
図の見方
GreenBlue
Blue
赤の線…主系
黒の線…副系
実線( )
…ユーザーのアクセス
破線( )
…動作確認のためのアクセス
…プロセス起動
…プロセス停止

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
両方主系にする(1/5)
Blue Green

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blueサーバーのデータ連携サーバーを
停止する(2/5)
Blue Green

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ロードバランサーを切り替える(3/5)
Blue Green

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blueサーバーを副系にする(4/5)
Green

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
副系になったデータ連携サーバーを起動する(5/5)
Blue Green

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ポイント
切替処理はCIサーバーからワンクリックで出来
るようにしている
切替処理に冪等性を持たせている

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
切替の手順自体は、システムの構成に依存して
いるので、汎用的にこの手順が使えるわけでは
ないです。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
なぜこうなるか
ロードバランサーやサーバーなど、複数の機器
の状態を手順を踏んで変更しているが、その操
作をアトミックにはできないため、両方のサー
バーが一旦主系になるなど、手順を踏む数が多
くなっている。
このこと自体は、どこでも起き得ることです。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
http://startupstockphotos.com/post/82514406502/we-create-here-in-the-making-folks-read-the-blog
Blue-Green
Deployment
を支える技術

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
自動化
切替時にロードバランサーやアプリケーション
の切替に複雑な手順を踏んでいますが、Blue-
Green Deploymentの導入前からリリースに関
する作業の自動化を地道に進めていたので、CI
サーバーからワンクリックで切り替えられるよ
うになっています。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
テスティング
データ連携に関係する主系・副系の切り替えの
ためのコード修正は、自動化されたユニットテ
ストとCIなしでは実現できませんでした。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
テスティング(2)
Blue-Green構築時のインフラ観点でのシステム
テストでは、Gebによる自動化されたend to
end のテストを最大限に活用しました。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
pull requestによるコードレビュー
• インフラの担当エンジニアがプロダクション
コードの修正をレビューする
• 開発の担当エンジニアがデプロイスクリプト
の修正をレビューする

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
Blue-Green Deploymentを支える技術
• 自動化
• テスティング
• バージョン管理

#ccc_g11
Copyright 2016 Hiroyuki Onaka
まとめ
「冗談じゃない、ベンダーは私達よ、他の誰でもない！私達が作って私達が運用する。
それ以外に技術屋の動きなんてありえない！」
- 夏見公司「なれる!SE3 失敗しない？提案活動」

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
最終成果
• 日中でのサービス無停止リリースが実現
• サービス無停止リリースを実現したことにつ
いて、お客様の企画部門で表彰される

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
コードレビューの事例に代表されるように、開
発チームとインフラチームが実現すべきゴール
を共有した上で、お互いの役割を発揮できたか
らこそ、Blue-Green Deploymentを導入でき
たと思います。

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
私たち、DevOpsしています(ドヤッ)

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
「素早くリリースする」のがDevOpsではない
「Opsの役割は、ビジネスを実現することであ
る」
- John Allspaw, 「10+ Deploys Per Day: Dev and
Ops Cooperation at Flickr」から

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
誰がDevOpsするのか
私はどこのポジションなのか

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
SlackをSIerに導入した話
小野和俊のブログ:SlackをSIerに導入した話。そしてSIerの未来
http://blog.livedoor.jp/lalha/archives/50528045.html

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
富士通がAdvent Calendarに参加することになった理由
富士通がAdvent Calendarに参加することになった理由 – blog
http://tnaoto.hatenablog.com/entry/2016/12/02/114611

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
• SIの現場でも技術の追求は出来ます
• オワコンではないです
• 僕たちの業界はもっとよくなれる

#ccc_g11
Copyright 2016 Hiroyuki Onaka
日本のDevOpsはSIがリードする
青空白帆(CC BY 2.1 JP)
http://photozou.jp/photo/show/254715/28171547

#ccc_g11
Copyright 2016 Hiroyuki Onaka
#ccc_g1
ありがとうございました！
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://blog.fieldnotes.jp/