✳︎社内向けです。(社内用語をそのまま記載しています)

ボルケーノ会議(2018/8に行われたSGEのあした会議)で提案、決議していただいた内容で、自分の働き方に関わる部分を説明したく、ブログに書きます

提案内容は2つありました。

(✳︎チームで議論して、提案した内容を自分視点で書いています)

1. 3社CTOの提案
SGEの各子会社の中で、今、注力すべき子会社3社に
自分がCTOとして入って強い組織にする、という提案です。

きっかけは、しょうごさんとCTO、CCOさし飲みで、刺激をもらったからです。
「自分の組織をもっていないことで、遠慮している時があるのではないか?」
とするどい突っ込みをいただきました。

その後、いろいろ考えるにつれ
・自ら現場に入って、現場のメンバーと同じ目線でもう一度働きたい。
当事者意識をもって、組織をつくることをもう一度したい。
・SGEの「組織は自分たちが作るもの」ということを体現したい。
強くそう思うようになりました。

「3社に注力したとき、SGEのCTOはどうするか?」
提案する前にチームで話になりました。
チーム内の結論は、3社CTOとSGEのCTOは両立しないから
SGEのCTOをおりないと、3社CTOは務まらない、という結論でした。

「SGEのCTOをおりる」ことを、自分自身に突きつけられた時、
正直、いやでした。
ただ次の瞬間、CTOをおりるのがいやと思っている自分がいることに

気づきました。

日頃、みんなには、「変化に対応しろ。ずっと変わらないことはよくない」
という話をしていたにもかかわらず、
そこには、SGEのCTOという立場にしがみつこうとしている自分がいて、
自分自身、かっこわるい、と思いました。

自分がみんなに伝えていることを体現するためにも、
自分自身が、変化する場に身を置き、成長しようとしている姿を
見せるべきだと、感じました。

現場に入るからには、みんなをがっかりさせるような働き方はできないです。
そういうプレッシャーの中でこそ、自分自身、成長できるのではないか。

そう判断し、SGEのCTOをおり、3社のCTOに集中する、という結論を出しました。

2. TEC8の提案
(✳︎TEC8:SGEのエンジニアボード)

自分の働き方をきめたとき、SGE全体のエンジニア組織はどうなるべきかを考えました。
結論からかくと、自分が中心となって動いていたSGEのエンジニア組織を
TEC8が中心となるようなエンジニア組織に変えて行くべき、と結論づけました。

自分がTOPでいることで、TEC8のメンバーの経験する機会をうばっているかもしれない、という、危機感は感じていました。
自然と、自分がケツを拭く安心感を与えてしまっているからです。

人が成長するのはどんなときか?
過去聞かれたことがあるのですが、
「自分自身でやりきらないといけない状況、後ろ盾がない状況でやりきったとき。」
「自分自身でやりきった、と思える状況で、成果をだしたとき」
人は成長すると思っています。

SGEのエンジニア組織全体の意思決定の場から、自分は身をひきます。

自分がケツを拭かない状況をあえて作り出し、
TEC8のメンバーがSGEという組織にきちんと向き合う場を作り出したいと思います。
TEC8のメンバーは課題感をもったメンバーで構成されています。
きっとやりきってくれるとおもっていますし、それがSGE全体の成長につながると信じています。

今回、様々な人に影響をあたえてしまう大きな決断をしたにもかわからず、
決議した内容を柔軟に対応しようとするSGEという組織は、改めてほんとうに良い組織だと思いました。

自分自身より高みを目指してかんばっていきます。

先日(12/19)、BASE株式会社が主催する「PHP Way #1」に
コネヒト CTO 島田さん、BASE CTO えふしんさん、と共に
登壇させていただきました。

 



きっかけは、PHP Conferenceの懇親会で、BASEのエンジニアの方と
もっと勉強会を主催した方がいいよね、という話が盛り上がりました。
その話をした後日、BASEの広報の方から、PHPを中心にした話題で
勉強会の登壇の打診をいただいたからです

当日のディスカッションでもお話ししましたが、PHPのサーバサイドが
盛り上がっている感じを作りたいと思っていたので、登壇を快諾させていただきました。

勉強会としては「PHPを使い続ける企業がどのようなことを考えて、その選択をしているのか?」
がテーマでした

SGEのゲーム事業では、主に使用しているサーバサイドの言語でPHPがあります。
SGEのPHPを選択している理由を中心にお話しさせていただきました。



資料にありますが、SGEは子会社複数社によって成り立っている組織で
各社の技術選定は、各社にまかされています。
各社ノウハウが分散しそうですが、それが起こらないように、共有の文化が浸透しており
多様性がありかつノウハウがたまる組織になるように日々横軸のつながりを強めています。

PHPという技術選択は、歴史的経緯もあります。
かくいう、私も、社会人として使用してきた言語は、SIerのときは、Javaだったのですが、
携帯(当時はガラケー)のコンテンツに携わる仕事からは、ずっとPHPを使用してきています。
2010年くらいまでのガラケーのサイトは圧倒的にPHPが多かった印象です。

発表およびディスカッションでいろいろなことをお伝えしましたが、
いままでPHPを使用して開発してきて感じたことを率直にお伝えしたつもりです。

PHPのコミュニティは懐が深く、PHPのコミュニティで学んだことを実務に活かし、
新たに取り組んだことをPHPのコミュニティに還元する、ということを
繰り返しています

PHPエンジニアがもっと幸せになるためには、自分たち自身が
PHPを楽しんでいることをアピールすることだと思っています。

ブログを書いてください、と参加者の皆さんにお願いしたにもかかわらず、
言い出しっぺの自分がかくのが遅くなりました。
参加者、およびこのブログをよんでくださったPHPのエンジニアの方が
自分たちのやっていることに自信をもち、
以前にも増して、発信していけるようになれば幸いです
 

遅ればせながら11月3日のPHP Conferenceで発表してきたことについて補足交え、ブログをかきます

発表資料は上記の画像のリンクからたどってみてください。 ちなみに動画で見たい方はコチラです
(動画がアーカイブされることを知らず、発表前、プラプラしているのを取られちゃってますが・・・)

 

kubernetesをつかいはじめ、もろもろつまづいたところをまとめ、今後のみなさんの導入の助けになれば、といった内容になっています。

スライドにもありますが、kubernetesの特徴として
・デプロイの自動化
・アプリケーションをスケーリング
・ハードウェアの使用を最適化
があげられます


用語が覚えるまでピンとこなかったので、用語の解説もスライドにのせています

kubernetesのPodの管理は非常に優秀で、基本的にDeploymentに状態を定義すれば、あとは気にすることはありません
Rolling Updateもすばらしい機能です

 

ただし、自分が携わっているゲームの運用において、Rolling Updateは運用上都合がわるいです。


ゲームでは、ユーザへ不公平感がでないようにすることが重要で、サーバの更新(プログラムの挙動の変化)がすべてのユーザ同時に起こることがのぞまれます。

たとえば、バトルに関するゲームで、スキルの発動の不具合を直すデプロイをしたとき、
ユーザが接続したサーバによって、スキルの発動結果が異なる結果になったら、公平感がなくなってしまいます。
そのため、基本的にはサーバの更新がサーバによらず、同時に反映されてほしいものです。

 

そこで、Rolling Updateではなく、ブルーグリーンデプロイをkubernetesで行うにはどうずればよいかを検証してみました。

発表スライドにありますが、以下、2種類の方法で検証、比較しています

(A) Ingress(LB)によるブルーグリーンの切り替え
(B)Serviceの振り分け先を変更することによるブルーグリーンの切り替え
です

 

発表スライドで試したときには、Node数3、Pod数3で試したのですが、今回、Node数、Pod数が多いときの挙動で、デプロイの動作に違いが出るかも同時に比較してみました。

以下、結果です(GKEで実施しています)


(1)Node数2、Pod数20の環境でIngressでBlue系をGreen系に切り替えたとき


縦軸はreq/s、横軸は、デプロイしてからの経過時間です。約80req/sのアクセスをしたときに、Blue系のレスポンスがかえってきたときは青のグラフ、Green系のレスポンスがかえってきたときは赤のグラフになっています(以下グラフの見方は同様です)

 


(2)Node数2、Pod数20の環境でServiceを更新してBlue系をGreen系に切り替えたとき

 

(1)と(2)を比べてわかることは、(2)の方が、Blue系のレスポンスが0になるまで時間がかかっているということです。
(1)は(2)にくらべ、Blue系のレスポンスが0になるまでの時間が短いです。
ただし、デプロイ後に直にGreen系のレスポンスがかえってくるわけではなく、Green系のレスポンスがかえってくるようになるまで1分くらいかかっていることがわかります。

 

次にNode数、Pod数を増やしてみた結果をみてみます。

 

(3)Node数20、Pod数200の環境でIngressでBlue系をGreen系に切り替えたとき

 

(4)Node数20、Pod数200の環境でServiceを更新してBlue系をGreen系に切り替えたとき

 

Node数、Pod数を増やしてみたところ、傾向は同じで、より顕著に違いがわかるようになりました。

LBで切り替える場合は、Node数、Pod数によらず、Green系のレスポンスが0になるまでの時間は(1)とくらべ、あまり変わりません
一方、Serviceで切り替える場合は、Node数、Pod数が増えると、Green系のレスポンスが、なかなか0にならないのがはっきりとグラフに現れています

 

上記検証結果をうけて、現時点(2016/11/9)のkubernetesのGKE上の動作では、ブルーグリーンデプロイを実施するのであれば、LBによる切り替えのほうが望ましい、と自分は結論づけました。

 

みなさんがkubernetesを使うときの参考になれば幸いです

 

最近、kubernetesをさわりはじめました。

チュートリアルやってもあれなので、Redmineを立てたときのTips的なものを。

ローカルの操作PCとしてMac
Redmine構築先はGCP上のGKEでRedmineを立てます。

ローカルのMacにはgcloudコマンド、kubectlコマンドが入っているとします。
(kubectlが入ってない場合は、gcloud components install kubectlでインストールしてください)

dockerコマンドをMac上で実行するので、dockerコマンドを
実行できる環境を用意してください。

ローカルでもkubenetesをつかいたいので
私は、minikube(https://github.com/kubernetes/minikube)をインストールしました。

お手軽にGKE上でRedmineをたてたいので、
すでに作ってくれた人のものを利用します。

https://github.com/bitnami/bitnami-docker

手順はここに書いてある通りなのですが、いくつか修正したので、そこを解説
https://github.com/bitnami/bitnami-docker/tree/master/gke/redmine


まず、minikubeをいれるとはまるのが、contextです

とりあえず、向き先を確認します。

$ kubectl config current-context
minikube

となっていたら、ローカルを見ているので、GKE上を見るようにします。

ちなみに、先にGoogleのconsole上でclusterをつくっておいてください。


$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: REDACTED
server: https:/XXX.YYY.ZZZ.WWW
name: gke_example_asia-east1-a_cluster-1
- cluster:
certificate-authority: /Users/example/.minikube/ca.crt
server: https://192.168.99.100:8443
name: minikube
- cluster:
certificate-authority-data: REDACTED
server: https://192.168.1.10
name: vagrant
contexts:
- context:
cluster: gke_example_asia-east1-a_cluster-1
user: gke_example_asia-east1-a_cluster-1
name: gke_example_asia-east1-a_cluster-1
- context:
cluster: minikube
user: minikube
name: minikube
- context:
cluster: vagrant
user: vagrant
name: vagrant
current-context: minikube


で作成済みのclusterを確認します。

GKEのcontextはgke_*ではじまっているやつです

$ kubectl config set-context gke_example_asia-east1-a_cluster-1

でGKEを向くようにします。

手順にもどると

まず、cloneします。

$ git clone https://github.com/bitnami/bitnami-docker.git

作成するRedmineの環境は
フロントにWebrikでうごくRedmine
バックエンドにMariaDBのMaster、Slaveの構成です

READMEには、Redmine、MariaDBのSlaveのPodsを複数にしてますが(replica=3)、
そんなにいらないので、それぞれ1にして構築します

まず、DBのストレージを作成します。

$ gcloud compute disks create --size 100GB mariadb-disk

ディスクの名前は、kubenetesのYamlに記載してあるので、あわせておきます。(mariadb-disk)

sizeは200GBが推奨(200GB未満だと、パフォーマンスがおちる)ですが、
そんなにデータをつくらないので、今回100GBにします

データベースのMasterをつくります。

cloneしたディレクトリのgke/redmine配下に必要なファイルがあります。

cloneしたものは、ReplicationControllerをつかっていますが、
Deploymentを使う事にします。(今後Deploymentが主流だと思うので)

mariadb-master-deployment.yml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mariadb-master
spec:
replicas: 1
template:
metadata:
labels:
app: mariadb-master
spec:
containers:
- name: mariadb-master
image: bitnami/mariadb:10.1.13-r0
env:
- name: MARIADB_DATABASE
value: redmine_production
- name: MARIADB_USER
value: redmine
- name: MARIADB_PASSWORD
value: secretpassword
- name: MARIADB_REPLICATION_MODE
value: master
- name: MARIADB_REPLICATION_USER
value: replication
- name: MARIADB_REPLICATION_PASSWORD
value: secretpassword
ports:
- containerPort: 3306
name: mariadb-master
volumeMounts:
- name: mariadb-persistent-storage
mountPath: /bitnami/mariadb
livenessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 30
timeoutSeconds: 1
volumes:
- name: mariadb-persistent-storage
gcePersistentDisk:
pdName: mariadb-disk
fsType: ext4


Deploymentを作ります

$ kubectl create -f mariadb-master-deployment.yml

正常に出来たかどうか確認します。


$ kubectl get pods -l app=mariadb-master
NAME READY STATUS RESTARTS AGE
mariadb-master-1674727184-ho215 1/1 Running 0 5s


つづいてサービスをつくります。
mariadb-master-service.yml

apiVersion: v1
kind: Service
metadata:
name: mariadb-master
labels:
app: mariadb-master
spec:
ports:
- port: 3306
targetPort: 3306
protocol: TCP
selector:
app: mariadb-master


$ kubectl create -f mariadb-master-service.yml

できたかどうか確認します。

$ kubectl get services mariadb-master
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mariadb-master 10.123.240.249 3306/TCP 5s


まずはここまで
つづきはまた書きます。
タイトル通りですが、
Androidの開発環境を、ローカルにつくろうと思ったところ
選択肢がいっぱい

次のサイトを参考にさせてもらったのですが・・・

Macで手軽にAndroidエミュレータを動かす方法いろいろ

おすすめのAndyが手元のMacだと起動しない・・・

そこでAndroid Studioをつかうことに
AndroidStudio

開発環境といいつつ、一番用意したかったのは
Androidエミュレータ

素直に本家からおとしてきてインストール

ちなみにバージョンは1.5.1

快適に動作させるためにはHAXMを有効にする

ここまではよかった。

Android Vitual Device Managerで
デバイス作成
AVDmaneger


Configurationでメモリーを設定
AVDConfig



ここで、HAXMのメモリーの設定はないなー、と
おもいつつ、作ったVirtual Deviceを起動・・・

ところが・・・・

emulator: The memory needed by this AVD exceeds the max specified in your HAXM configuration.
emulator: AVD RAM size = 1536 MB
emulator: HAXM max RAM size = 512 MB
emulator: You might want to adjust your AVD RAM size and/or HAXM configuration to run in fast virt mode.


HAXMが有効にならない!
AVDのRAM sizeと
HAXMのRAM sizeが違うからおこられている!

HAXMのRAMの設定を散々探したので、同じようにハマった人向けにメモ


avdのイメージは
Macのユーザだと

$HOME/.android/avd/イメージの名前.avd
配下にできます

ここに

hardware-qemu.ini

があるので、おもむろに開くと

hw.ramSize = 512

があります!

これを、

config.iniの
hw.ramSizeと同じにします(こちらはGUIの画面で指定した値です)


これでエラー解消!