読者です 読者をやめる 読者になる 読者になる

Goldstine研究所

mosuke5's tech blog

参加してきた、MSPJマイグレーションコンペ2017winter

クラウド Azure AWS MSPJ マイグレーション MSP

先日、2017年2月18日に「MSPJマイグレーションコンペティション2017winter」に参加してきた。
MSPJマイグレーションコンペティション2017winterとは、
日本MSP協会コンペティショングループが主催する、 次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目指したコンペティションです。

もう少し平たく言うと、MSP事業者の本当の業務に近い形でのコンペを通じて、スキルアップを図りましょうというものだ。
自分はMSPの人じゃないけど参加は全然できました。

connpass.com

競技ルール

今回の競技のお題は、
AWS上で動作しているレガシーなRedmineをAzure上に移行する」というものだ。

このコンペの特徴としては、実際にMSPでの業務に則し、お客さんから曖昧な要望を受けている部分や、
お客さん側にしかない権限については、お客さんと調整する必要があることです。
例えば、環境の移行する際にはDNSの切り替えが必要だったのですが、DNSの設定権限は我々にはなくて、
Slackを利用して、DNS設定変更依頼や作業周知を出さなければいけなかった。
このあたりはとてもユニークなポイント。

お客さんから移行について以下のような曖昧な要望をもらっている状態でした。

<要望>
- 今の環境を新しい環境に完全移行して欲しいです。
- 実施した内容と結果については報告が欲しいです。
- システムを止めるときは利用者に告知が必要なので連絡が欲しいです。
- 昔から使っている古い環境なので、バージョンアップして欲しいです。
- できれば利用者に影響を出さないように切り替えたいです。
- できればサーバに関する資料があるとありがたいです。
- できれば今はまったくバックアップを取っていないのでバックアップを取れるようにしたいです
- できれば今後は利用者が増えるのでシステムを冗長化したいです。
- できれば新しいインフラエンジニアに引継ぎするために必要な情報がまとまっていると嬉しいです。

<担当者のコメント>
- 前任のインフラエンジニアが辞めちゃったのでこのシステムもう分かる人がいなくって。
- 結構前から使っているので環境も古くなっているみたいで、OSのサポートがもうすぐ切れるって話を聞いたものですから、セキュリティとか色々心配で何とかしたいんです。
- みんなこのシステムを結構便利に使っていてくれているようだから、システムを切り替えるときは連絡しないとなぁ。
- そうそう、近々新しいインフラエンジニアが入社予定だから、その方に引き継げるようになっていると嬉しいですね。

ちなみにチームについては、当日の参加者で適当に3人チームを作って行いました。
一緒の参加者が同じチームにならないように調整されます。

構成把握

開始後、まずやったことが環境・構成の把握。
ざっと下記のような感じ。ログインしてすぐに、pstree みて大体の構成を把握しました。

  • インフラ: AWS(EC2)
  • OS: CentOS5.2
  • Webサーバ: Apache2.0 + Passenger
  • DB: MySQL5.1
  • Ruby: 1.9
  • Redmine: 2.3
  • DNS; Route53で管理。権限はお客さんのみ
  • サーバ構成: サーバ1台のシングル構成

移行作戦

細かなバージョンはおいておいて、最終的に目指す構成は下記のようにした。
これに至った考え方とかは下に書く。

f:id:mosuke5:20170220165739j:plain

冗長化の観点

まず、Webサーバをロードバランサを利用して負荷分散と冗長性を確保した。
Azureではロードバランサーのフルマネージドサービスがあるので、
ロードバランサー自体の冗長化については考える必要がなかった。

Azure Load Balancer の概要 | Microsoft Docs

次にデータベースだが、当初ロードバランサと同様にマネージドサービスがあればそちらで対応しようと検討していた。
SQL Databaseというサービスがあるのだが、「Microsoft SQL Server エンジン」のみの対応とのことで、
今回のRedmine移行には適切ではなかった。

SQL Database とは SQL Database の概要 | Microsoft Docs

ということで、MySQLレプリケーションを使ったデータベースを作ることにしたのだが、
自前で作っている余裕はとてもなかったので、マーケットプレイスから
MySQL with replicationというイメージを見つけて対応することとした。

Microsoft Azure Marketplace

最後に、Redmineでは添付ファイルのアップロードなどをすることがある。
ロードバランサーで負荷分散環境においては、添付ファイルを共有する必要がある。
手っ取り早くRsyncでの同期をする方向にした。

バージョン関連

移行先の各種バージョンは下記とした。

  • OS: CentOS7.2
  • Webサーバ: Nginx
  • DB: MySQL5.7
  • Ruby: 2.2(アプリケーション実行はthin)
  • Redmine: 2.6

はじめRuby2.4で検証していたのだが、
さすがにRails3はRuby2.4では動かずRuby2.2まで下げた。

Webサーバ、アプリケーションサーバ関連

移行元の環境では、RedmineApache+Passengerで動作していた。
余談になるが、Passengerはmod_railsなんて呼ばれることもあって、いわゆるmod_php, mod_perlと同じ方式での動作方法。

昔にPassengerインストールでハマった記憶もあるし、特にPassengerである必要性はなかったので、
馴染みのあるNginx+Thinの構成で動かすこととした。
※Thin部分はpumaでもunicornでもお好きなものをどうぞ。

この構成はWebサーバとアプリケーションサーバを分離するアーキテクチャ
Thin単体でも動作させることができます。Nginxはリバースプロキシや静的ファイルの配信に特化し、
アプリケーションの実行はThin側に任せるものになります。

正直どちらでもかまわないのだが、Passengerを利用する場合、
アプリケーションとインフラのApache部分と密な関係になってしまうのが煩わしいと個人的に思ってます。
まあケースバイケースでしょうが。

※あと最近Apache触ってなさすぎて忘れた…

移行作業

作戦が決まったところで、さっそく移行作業なのだが、
いきなり完成形に持っていくことは難しいと考えいくつかのステップに分けて移行作業を進めた。

Step1:まずはAzure環境へ

f:id:mosuke5:20170220173855j:plain

Step2:冗長化とか

f:id:mosuke5:20170220173905j:plain

Step3:最後の仕上げ

f:id:mosuke5:20170220173915j:plain

Azureのここがよくわからなかった

限られた時間内で、ほぼ初めてAzureをまともに使ったわけだが、
いくつか概念の理解や操作方法がわかりづらいなと感じた。
(IsuconでもAzure触ったが、あれは本当にサーバ起動するだけなので…)

ネットワーク概念

Virtual Private Networkの概念がとてもわかりづらかった印象。
買ったリソースをどうやって、指定のネットワークにデプロイするのかなど。
慣れの問題も大きいとは思うが、当日はほんとにわからなかった。

サーバのイメージ作成

すごい初歩的なことだが、構築したサーバのイメージを作成して、複製することがとても難しかった。
メンバーがいろいろ躓いていたので、最終的に普通にもう1台構築するという強行手段を取った。
このところは、クラウドに携わるものとして仕様確認しておきたい。

仕事で使っているクラウドAWS的なため、
AWSの考え方にFitするものはすぐに理解できるが、Azureはまた独特の概念が多い印象。
これだけAWSが使われている現代に、「AWS的」であることは価値がある!??

結果、懇親会とか

んー。結果は優勝・準優勝ではなかったんですが、
きっとテストちゃんとしないで移行したので、きっと触るとなにか抜け漏れがあったのでしょう(笑)
また来年あれば参加したいなと思える楽しいコンテストでした。
ISUCONに続き悔しい結果。

参加者の中には、MSP業界の方がもちろんたくさんいた。
懇親会でいろいろ話をしたけどざっくりこんな課題を抱えている人が多かった。

アプリが悪い問題

MSPなのでお客さんのシステムの運用を請け負います。
その業務の中には障害対応や監視設定、デプロイとか様々あるわけですが、
アプリの作りにより、監視設定できないことや自動化できないことが多数あるそうです。
お客さんのせいにしてはいけないのだけど、その点が一番しんどそうだった。

自動化・コード化

MSPの方々も本当は監視やデプロイなどの自動化するコードやツールを作ることに力を入れたいけど、
単純な手順書作業や日々の障害対応に追われてなかなかできないとか。
そもそも普段コードを書く仕事ではないので、そのメンテするチーム体制が取れないという問題も。
(それは前の仕事でもよく聞いた話だなぁ~)

オンプレ

まだまだオンプレ環境の運用も多く、
ハードウェア交換やハードウェアによる障害には悩まされているとのこと。
聞いてる話だと、あえてオンプレにしているというよりはレガシーで残っているのが多いっぽい。

夜勤

夜勤の週は、5日間夜勤をする。そういう運用らしいです。
前の仕事では身近にネットワークの運用部隊がいたので夜勤事情はよく聞いていますが、 まったく考え方が違くてびっくり。
でも意外と、週ごとに別れている方が辛くないらしいよ?

最後に

一緒に戦ってくれたチームメンバーありがとうございました。

去年のお題はVPSからクラウドへの移行だったらしいですが、今回はクラウドからクラウドへの移行。
このあたり、そういう時代のフェーズに入ってきているということなんでしょうか。
きっとそういうことでしょう。

特定のクラウド独自の機能を使っていなければ、移行自体は簡単で、
それよりももともとのレガシーシステムをバージョンアップするほうがしんどい印象でした。
クラウドロックインとどう向き合っていくか、考えなければですね。

Cookpad TechConf2017にいってきたメモ

CookpadTechConf 海外進出 機械学習 スケーラビリティ

はじめに

CookpadTechConf2017に参加してきた。
昨年は抽選に外れていけなかったのでよかった。

techconf.cookpad.com

おなじみCookpadが年に一回行っているテクノロジーカンファレンス。
1年間のクックパッドでの取り組みを発表する場。

完全メモ書きではあるが、ご活用ください。

クックパッドの取り組み

セッションはたくさんあったが、クックパッドが今年1年間で取り組んできた大きな内容は以下3つと感じた。

  1. 海外進出
  2. 機械学習への取り組み
  3. スケールへの対応

海外進出の話は今まではほとんど聞いたことなかったので、本格的に力を入れ始めたというところだろう。
機械学習への取り組みは去年からと明確にいっていたのでこちらもそう。
最後のスケールへの対応は今までもたくさん発表してきたが、そこに大きな波がもう1つやってきた。後ほど。

海外進出

Go Global

  • 宗教、言語、気候によってサービスを変える
    • 同じ言語圏であっても気候が違えば違う食文化がある
    • 例えばスペイン語圏でも、スペインと南米では全く食文化が異なる
  • どうやってサービスを作っていくか
    • あたりまえ品質
    • グローバリゼーションとローカライゼーション
  • 検索のローカライズははてしなくどろくさい
  • 翻訳もとんでもなく大変
    • Amazonの例だが、Kindleで"OR"で誤訳があった
    • プレミアムという言葉も実は難しい
      • プレミアムというのは地方によってはプレミアムでないものを差別する用語として使われることもある
      • プライムやプレミアム、エクストリームなど使い分ける
  • 国際チームは国籍がみんなばらばら
    • それぞれの考え方も文化も異なる
    • 最終的なアウトプットだけ共有しあとはまかせるというスタイルをとっている

Global Infrastracture

  • 多くのリージョンへ展開している
  • グローバルアプリはスクラッチで新規開発
    • いまは普通のRailsアプリ
    • 日本のCookpadとはUIも全く異なる
  • グローバルのインフラについて
    • us-east-1のサーバを利用
    • データベースはAurora for MySQL
    • Elasticache利用
    • nginx, unicornの構成
    • CDNはFastly
  • 地域によってトラフィックピークが全く異なる
    • 日本だとバレンタインシーズン
    • イスラムではラマダンと呼ばれるシーズンがある
      • しばらく断食していたその後に食事を楽しむ時期

Go Global - #CookpadTechconf 2017 // Speaker Deck
Building infrastructure for our global service // Speaker Deck

機械学習へのとりくみ

Real World Machine Learning // Speaker Deck

スケーラビリティへの対応

  • Railsアプリでは世界最大規模
    • モノリスティックに構築して巨大化しすぎた。。。
  • サービスの分割化、マイクロサービス化を促進
  • マイクロサービス化、それゆえにおこる問題が起きてくる
    • サービス間の連携がとても重要に
    • 次の仕組みを使って連携を強化
      • 障害を制御する => Expeditor
      • 障害を予防する => Pact
    • Expeditor(内製ソフトウェア)
      • 1)サーキットブレイカー
      • 2)並列処理
      • 3)リトライ処理
      • もともとは並列処理のために作ったがサーキットブレイカーの機能が重宝
      • netflixNetflix/Hystrixにインスパイア
    • Pact (https://docs.pact.io/)
      • サービス間の連携テストを行うソフトウェア
      • これは外部開発のソフトウェアだが周辺ツールは内製
  • マイクロサービス化したのでDockerでサービスのポータビリティも上げた
    • Dockerをより良く使うためにHakoというDockerデプロイツールも開発
  • その他、スケールに対応するために幾つかのソフトウェアを内製
    • Kuroko2
    • barbeque
  • これらの内製ソフトウェアはすべてRubyで書いている
    • なぜRubyか?
    • 好きというのもあるが、統一することで品質やスキルの担保ができる
  • でもRubyには速度の問題などあることは承知。。。
  • すべてのデータをRedshiftに移行
  • スポットインスタンスの利用でAPIサーバのコストを60%下げた

Cookpad Under a Microscope // Speaker Deck
Cookpad awakens // Speaker Deck
Spot Instances in Cookpad #CookpadTechConf 2017 // Speaker Deck

クラウド上でのWordPressのスケールアウトを考える

WordPress クラウド AWS Alibaba Cloud 分散 スケールアウト

複数台サーバでのWordPressの構築・運用について考える。
実際に、とあるクラウドで分散環境のWordPressを構築したのでその知見をまとめる。
なるべく特定のクラウドに特価しないものとして記載したい。

やりたいこと

  • スケールアウトできるWordPress環境を作る
  • SSLに対応する
  • HTTP/2に対応する
  • AWSなどのクラウド環境で構築する

アーキテクチャ

まず先に全体のアーキテクチャ図から示す。
これから各項目について解説していく。

f:id:mosuke5:20170104185455p:plain

SSL・HTTP/2への対応

まずSSLへの対応だが、通常ならばロードバランサをSSLの終端とし下記のような構成にすることが多いだろう。
この場合はロードバランサをL7のものとして稼働させる。

f:id:mosuke5:20170104190001p:plain

しかし、HTTP/2に対応しようと思うと事情は異なってくる。
(もちろん、最近ではAWSのALBのようにHTTP/2に対応する製品がでてきているのは承知だが。)
現在のパブリッククラウドで利用できるロードバランサの多くはまだHTTP/2に対応していない。
そのため、ロードバランサをL4として稼働させ、配下のWebサーバにてHTTP/2を処理する必要がでてくる。
この場合、ロードバランサはTCPでポート443を待ち受けるようにし、配下のWebサーバへポート443のままでフォワードすればいい。

f:id:mosuke5:20170104185953p:plain

クラウド環境ではWebサーバがスケールすることは前提にいれることがおおい。
そのため、この場合のSSL証明書はN台に対応した製品を買う必要がある。
例えば以下のような製品など。

データベースの分離

分散環境でのWordpressでは共通したコンテンツを配信するため、データベースはもちろんWebサーバとは分離したほうがいい。
それぞれのWebサーバは共通のデータベースを見に行くべきだ。
データベースを自前で冗長化しても構わないが、それなりの運用コストがかかることは容易に想像がつくので、
クラウドのマネージドデータベースサービスを利用した。

管理画面

管理画面のみを分離するアーキテクチャも考えられるが、ここではそうしないこととする。
管理画面へのログインセッションの保持は、別途KVS(RedisやMemcached)に保存してもいいと思う。
ですが、WordPress4.0以降ではデフォルトではMySQLへセッションを保存するので必須の対応ではないといえる。

github.com

記事で使うアップロード画像などの対応

管理画面から記事を投稿するとする。
記事のデータはデータベースに保存されるためどのWebサーバからも記事を参照できる。
しかし、記事に含まれる画像データはどうだろうか。

通常のWordpressでは管理画面サーバの/wp-content/uploads以下に画像を保存する。
複数台Webサーバがある状態で、たまたまアクセスしているサーバに画像を保存しても、他のサーバからは参照することができない。

これに対するソリューションはいくつかあるだろう。
例えば、rsyncなどを使って他のサーバと画像ファイルを同期するとか、画像用のストレージを用意しNFSで参照するとか。
冗長化の観点からもここはオブジェクトストレージのサービスを利用するのがいいだろう。

例えば、下記のような製品だ。

クラウドのオブジェクトストレージとWordPressを連携するプラグインは多く出ている。

デプロイへの対応

Wordpressのコードのデプロイ、Webサーバの設定変更などにどう対応するか。
ツールはなんでもいいが(シェルスクリプトでもいいし、Ansible,Chefなどでも)、
デプロイツールなど用いて全台サーバにデプロイできるようにしておくといいだろう。あたりまえ。
影響の大きいデプロイをするときはロードバランサーから切り離してデプロイ、テストとやるといいと思う。
あるいは、新しく構築(デプロイ)した別のWebサーバインスタンスを用意し、ロードバランサーで向き先を変更してもいい。

ロードバランサー配下のWebサーバはプライベートネットワークに配置しておりインターネットから直接アクセスできない。
そのため、デプロイサーバを用意することでデプロイできるようにした。
あるいは、踏み台サーバを用意して、多段SSHを使ってもいいかもしれない。

さいごに

他にも、工夫した点などはあるが、WordPressのスケールアウトという点に絞って簡単にまとめた。
OSSの利用は簡単だが、そのスケールや冗長化は毎度悩まさせると感じる。
以前もGitlabを運用してた時に冗長化をどうするか考えていたのを思い出す。

「嵐」 2016年振り返り

パブリッククラウド Alibaba Cloud SBクラウド 振り返り

だいぶお久しぶりのブログ。 そして恒例の年振り返りブログ。ついに2016年も終わってしまう。

というわけで2016年を振り返りたいと思う。
一応このサイトは技術ブログのはずなんだけど、プライベートのことが大いに混ざったポエムになってしまった。

なんの変哲もないはじまり

2016年のはじめのほう。振り返ってもとくに振り返ることがあまりないくらい変哲もない日々だった。
嵐の前の静けさだったと今思う。

TDD研修、プロマネ研修

後述するが8月までは、社内システムのエンジニアとして活動していた。
いつもどおり、内製開発のチームをどう強くするかばかり考え働いていた。

そんななか、新しい開発チームの模索のために部署を代表としてTDD(テスト駆動開発)の研修や、
プロジェクトマネージャーの研修など受けさせてもらった。

そのなかでもTDD研修はとても印象深い。
なぜなら、私が気に入っていた「Rubyによるデザインパターン」の翻訳者の一人が講師だったからだ。
さらには、研修の受講生は2人しかおらず、徹底してTDDを実践できた。
こんな恵まれた外部研修があるもんかと、感心したのを思い出す。

Rubyによるデザインパターン

Rubyによるデザインパターン

Gem公開、ATP-stat開発

会社のとあるプロジェクトでRails使うことになり、
趣味がてらにRailsを使ってATP-statというサービスを開発していた。
正直、ほんとに趣味で作ったものでクオリティは全く高くないし、最近はメンテもできていない。

AtpStat

また、このサービスに利用する仕組みをAtpScraperというGemにして公開した。
これは、せっかく受けたTDD研修を活かして、テスト駆動開発で行ったりしていた。

github.com

と、まあさほどいままでと変わらない感じの日々を送っていた。
だが、6月くらいから嵐が吹き始める。
プライベートでかなりショッキングなことがあった。ショッキングであると同時に生活がだいぶ変わるようなこと。
それだけでもショッキングではあるのだけれど、その出来事はなにかのトリガーを引いてしまったようだ。
世界線が変動したのかもしれない。

異動

まず、ショッキングな出来事からわずか1週間後に、社内転職の結果がでた。
詳しくは下記のブログを読んでほしいが、パブリッククラウドを提供する新規事業を行う会社に行くことになったのだ。

mosuke5.hateblo.jp

仕事環境の変化

仕事の環境は劇的に変わった。正直何もかもが違うといっても過言ではない。
変わった項目をまとめてみた。

項目 前の仕事 今の仕事
システム種別 ネットワーク監視システム パブリッククラウド
職種 システムエンジニア セールスエンジニア?
組織規模 大組織の中の1部署で100人程度 会社全体で数十人
チーム エンジニアのみ エンジニア、営業、マーケティングなど
お客様 社内 社外
ほぼ100%日本人 半分くらい外国人
英語 利用しない 飛び交ってる

実際の仕事

セールスエンジニア

最初に断っておくが、今の職種をセールスエンジニアというと少し語弊はあるのだが、
そういう一面があることは確かなのでそういうことにしておく。

今までやってきた開発エンジニアとはまったく異なった難しさを感じている。
お客さんはシステムを開発運用する現場のエンジニアの方であり何かしらに課題点を感じている人たちだ。
その課題についてソリューションを提案する必要があるわけであり、実際に自分が経験したことのないレベルで語ることは難しい。
自分が売る製品に知っているのは当たり前であり、それ以上に運用現場のことについて精通していてこそ仕事になる感がある。
職種的には運用現場から離れることになるわけだが、そこに精通し続ける必要があるのはとても難しさを感じとともに、だからこその価値と感じる。

どうやって現場感覚も失わないでいるか、課題の1つである。

そういえばこんな記事ありましたね。
はてなの中でたった1人!Mackerelを支える「セールスエンジニア」って何だ!?|転職ドラフトReport

サービスローンチ

異動したときの会社のミッションはAlibaba Cloudの日本リージョンの開設だ。
とにかくそれに向けてもろもろの準備をしてきた。
まずは、リリースできたので宣伝しておきます(笑)

jp.aliyun.com

www.sbcloud.co.jp

Gihyoデビュー

日本リージョンのリリースに伴って、Gihyoにデビューしました。
あとSoftwareDesignとWed+DB Pressに掲載されてます。みんなみてね。

gihyo.jp

英語

コメント省略します。がんばりゅ…

ISUCON6

念願のISUCON6に参加した。圧倒的な力不足を痛感。
力不足を実感したこと自体とてもいいことだったし、またISUCON対策で得た知見は確実にいいものとなっているのでよし。
来年も出れたらリベンジしたいです。

mosuke5.hateblo.jp

Mac

長年Macを使ってたけどやめた。 本当は新MacBook Proが出たら買おうと思っていたんだけれど、
USB Tpye-Cしかないことと値段の高さにThinkPadをかってしまった。
この件については別途ブログを書きたいと思う。

ThinkPad T460s - 14.0型 ハイパフォーマンス・スリム・モバイル・ノートブックTシリーズ| レノボジャパン

Macが目的というよりは、一度いい機会なのでMacを離れてみようという感じ。

今のPC状況
種類 PC
会社 MacBook Pro
自宅ノート ThinkPad T460S Windows10
自宅デスクトップ 自作PC Ubuntu16.04

一人暮らし

一人暮らしも決めた。引っ越し自体は2月予定だが、物件は決めて申し込みした。
なんだろう、勢いでこういうことになった。

最後に

今年は気持ちの面、生活の面、仕事の面といろいろと変化が大きかった。
これで嵐は吹き終わるのだろうか。それとも続くのだろうか。
それはわからないけれど、次に来る変化も受け止め楽しむことにする。

去年の抱負的なこと

せっかくなので去年の振り返りブログに書いてあった抱負的なことを振り返ってみる。
あんまり達成度はよくないけど、それ以上にいろいろあったからいいか。

項目 達成 コメント
Vim::Factoryを自分が使いたいと思うようなサービスにする × 検討したが、サービスの方向性を見失った
Vim::Factoryをベースにより自分たちが学習できる環境を作る 基盤は勉強材料としては活躍している
引き続き、インフラ系エンジニア?っぽい感じで邁進する 現場のエンジニアではないが、クラウドインフラよりで頑張ってる
ISUCONにでます(あれば…) 結果は惨敗
来年の抱負的なこと

大きく2つの面で頑張りたいと思ってる。
1つは、技術面の話。
今の職種は現場の開発エンジニアでもインフラエンジニアでもない。 しかし、パブリッククラウドを使うのは現場エンジニアであり、その感覚を忘れてはいけないと常に思っている。 プライベートでは今まで通り何らかの形で開発エンジニアをやっていたいと思う。

また、パブリッククラウドはシステムを開発・運用していく中で必要なサービスが盛り込まれている。
今まで以上に幅広い視野を持ってテクノロジーと向き合わなければいけない。
トレンドやツールの使い方とかに流されない、基礎的な部分をきちんとみていきたい。

2つは、技術面以外の話。
我々の仕事はシステムの開発ではなく、パブリッククラウドのビジネスを技術面から理解し支援することが大事。
そして、サービス利用者のビジネスについても技術面から理解し支援しなければいけない。
じゃ、なにをするのかっていうと難しいんだけど、テクノロジーの範囲を超えてビジネスモデルなどに意識してみようと思う。

そんじゃーね。

三葉よ、サーバーレス、それもまた結び。

serverless サーバレス クラウド lamda FaaS ServerlessConf

タイトルちょっとふざけました。 (が、半分本気。最後の方でわかる。)

ServerlessConf Tokyoに参加してきた。
今年8月からパブリッククラウドの事業に異動していて、(異動ブログ
開発者の立場よりクラウド提供側の立場として参加してきたので、また面白かった。

せっかくなので、自分なりにサーバレスについてまとめる。
新しいことというよりは、自分の中での整理した感じ。

1. サーバレスってなんだっけ

カンファレンスの中でもサーバレスの定義についてはいろいろな意見がでていた。
Martin Fowlerのブログではサーバレスの定義として下記2つが書いてある。

  • BaaS (Backend as a Service) : ex) firebase
  • FaaS (Function as a Service) : ex) AWS Lambda

martinfowler.com

ですが、ここでは焦点を絞って話すためにもFaaSということにしておく。
主にFaaSについて話したいのと、BaaSもいれてしまうとSaaSもサーバレスとかややこしいことになるので。

AWS Lambda

なんといってもサーバレスの概念を推し進めたのはAWS Lambdaでしょう。
説明はいまさら不要だと思うが、少しだけ。

コードを AWS Lambda にアップロードすると、サービスが AWS インフラストラクチャを使用してコードの実行を代行するコンピューティングサービスです。コードをアップロードして、Lambda 関数と呼ばれる関数を作成することで、AWS Lambda がコードを実行するサーバーのプロビジョニングおよび管理を行います。(https://aws.amazon.com/jp/lambda/details/)

課金モデルは関数呼び出した回数、および実行に利用したコンピュートのスペックによって決まる。
また特徴的なことは、AWSの他のサービスで発生したイベントをトリガーに実行できること。
例えば、Amazon S3にファイルアップロードされたことをトリガーにLambdaを実行できるのだ。

サーバレスの特徴

サーバレス自体そしてサーバレスで実装することの特徴しては下記がある。

  1. クラウド上のイベントを契機に実行できる
  2. 実行環境は、immutableで時間が立つと消える
  3. 実行環境は独立していて、コードは基本的にstatelessである
  4. 上記のようにimmutableでstatelessな構造につくるからこそスケールしやすい

2. どんな用途で利用しているか

クラウド基盤のイベントをトリガーとして

個人的に一番強力だと思っている使い方。上で説明したとおりだが、クラウド上のプロダクトに対してのイベントをトリガーに処理を行うことができる。
例えばこんな場合を想定してみよう。

ユーザが写真をアップロードするサービスで、アップロードした写真にたいして何かしらの画像解析をしてメタ情報を持ちたいとする。
ざっと従来のやりかただと2つくらいやり方が思い浮かぶ。

(1) アップロードするたびにアプリケーションサーバで画像解析をする
  • 解析にほとんど時間がかからない場合などはこれでいいと思う
  • 時間がかかるようなだとユーザへのレスポンスが遅くなる
  • 速くしようと思うとスケールアップで対応するしかない(やばい)
(2) バッチ処理でやる
  • バッチ処理で画像解析はまとめてやる。一番よくあるのでは?
  • 例えば5分に一度のバッチ処理で、5分間にたまった写真にたいしてまとめて処理する
  • バッチ処理でまとめて処理した場合、どこかでコケたときが辛い
  • この例ならそうでもないが、バッチ処理ではたいていスケールアウトが辛い

このケースに対してLambdaであればどうなるか。
1000件のアップロードに対して、1000回のLambda実行によって対応できる。
これは何万件きても同じことで、スケールの面で大変優れている。
また、1件ごとに処理するため、エラーが発生した場合に原因などとても追いやすい。

アプリのAPIとして

AWSでいうと、API Gatewayと組み合わせて、APIサーバとして利用するケース。
S3などのデータストアに直接アクセスできるように作ることもできるため、ファイルアップロードなどで使われることが多いとか。
個人的には今のところあまり魅力的には感じない使い方。

事例紹介

カンファレンスのなかで日経新聞社さんののサーバレスアーキテクチャの事例が一番よかったのでぜひ目を通しほしい。

speakerdeck.com

ポイントとしては下記。見事にLambdaの特徴を活かした利用をしている。

  • 新聞は基本的には朝刊と夕刊の2回で限られたときだけ処理する点
    • 常時稼働させたくない。EC2立ち上げっぱなしにする必要がない。
  • しかし、号外や速報など臨時の場合もただあり、それにも備えられる点
  • 日によってニュースの量が異なるため、いつでもスケールできる必要がある点

3. クラウドベンダーからみたサーバレスの立ち位置

クラウドベンダーにとってサーバレスはどういう立ち位置なのだろうか。
ぼくは「各サービスの横串」と考えています。
EC2、S3、RDSなどなどそれぞれのサービスは単体としてとてもよくできている。
しかし横の連携をしようと思うと別途様々な工夫が必要なのが現状だ。

サーバレスはその横の連携を担うのだ。
各サービス間を紐で固く結びつけてしまう。クラウドロックインを加速させる役割も持つ。

「三葉よ、サーバレス、それもまた結び。」

そして、IoTへの布石。
IoTの世界ではリアルタイムなセンサーの情報のやりとりでデバイスとデータセンタ間の通信遅延が許容できないことがある。
そこでいま研究が進んでいるエッジコンピューティング(フォグコンピューティングとも)などがあるが、
LambdaのようにImmutable, Statelessが前提で作られる、どこの環境でも実行可能な状態はIoTと相性がいいようにみえる。

今後どうなっていくかはわからないが、
バイスに近いエッジコンピューティング側はLambdaでさばき、そのさばいたデータを中央のデータセンターへ、
なんていうことが主流になってくるかもしれない。と思うとFaaSの存在は見逃せない気がしてくる。

ISUCON6予選で惨敗した. 足りなかったのは'Courage'

ISUCON 惨敗 ISUCON6

Applekeynoteで話題の'Courage'使ってみた笑

ISUCON6予選で惨敗した。(18000点くらい)
端的に言って、とても未熟だった。

とはいえ、とてもいい思い出になったのでまとめる。

メンバー

スリーエムというチーム名で、@mogulla3と@mintsu123と一緒に出場した。
ふたりともぼくよりもアプリの改善などは10倍くらい優秀なエンジニアなので、
ぼくはインフラとか総務的な立ち回りをして、2人がチューニングに集中できるようにすることを心がけていた。

準備

準備は3週間の間に土日どちらかに集まってISUCONの過去問を解いたり戦略について事前に打ち合わせしてた。

  • プライベートレポジトリの用意(Gitlab)
  • チャットルームの用意(Slack)
  • ISUCON4とISUCON5の予選の過去問解き
    • 土日集まったときには戦略や振り返りを重視
    • 実際の過去問ときは平日に各々が空いた時間などにやってた
  • 基本戦略を準備
    • なんの技術を主に使うか
    • だれが何を担当するか
    • 定形作業の手順化
    • その他ナレッジなど

採用した技術

  • PHP 7.0
  • php-fpm
  • Openresty(nginx) 1.11
  • MySQL 5.7
  • Redis 3.2

当日

出だしはとても順調だった。
Azure担当だったぼくはすぐにサーバをデプロイし、OSバージョンを確認した。
予想通りのUbuntu 16.04であったので、準備したとおり必要なミドルウェアのインストールをすませた。

ほぼ定石と言える下記(定形作業と呼んでいた)もすぐにこなすことができた。

  • 調査のための各種ログ出力化
  • Nginxでの静的ファイルの配信、キャッシュ化
  • Kataribeインストールと実行
  • MySQLのインデックスの付与と設定見直し
  • php-fpmのUnixドメインソケット化
  • デプロイの仕組みの整理
  • 不要デーモンの停止

この状態でもスコアは0のままであり、少し焦りを感じたが、
ここからが本番のチューニング開始である。
Kataribeの結果から、GET /が改善ポイントであることは明らかなのはわかっていた。

Top 20 Sort By Count
Count    Total      Mean    Stddev     Min   P50.0   P90.0   P95.0   P99.0     Max  2xx  3xx  4xx  5xx  Request
  326  366.105  1.123021  2.619395   0.000   0.000   6.188   7.418   9.827  10.207  326    0    0    0  GET / HTTP/1.0
  326  366.154  1.123172  2.618228   0.000   0.001   6.190   7.418   9.778  10.207  326    0    0    0  GET / HTTP/1.1
  240    0.000  0.000000  0.000000   0.000   0.000   0.000   0.000   0.000   0.000  240    0    0    0  GET /css/bootstrap.min.css HTTP/1.0
  240    0.737  0.003071  0.002843   0.000   0.002   0.006   0.010   0.013   0.015  240    0    0    0  GET /css/bootstrap.min.css HTTP/1.1
  120    0.101  0.000842  0.002078   0.000   0.000   0.002   0.003   0.015   0.015  120    0    0    0  GET /img/star.gif HTTP/1.1
  120    0.000  0.000000  0.000000   0.000   0.000   0.000   0.000   0.000   0.000  120    0    0    0  GET /js/jquery.min.js HTTP/1.0
  120    0.000  0.000000  0.000000   0.000   0.000   0.000   0.000   0.000   0.000  120    0    0    0  GET /img/star.gif HTTP/1.0
  120    0.152  0.001267  0.001788   0.000   0.001   0.003   0.004   0.011   0.012  120    0    0    0  GET /css/bootstrap-responsive.min.css HTTP/1.1
  120    0.000  0.000000  0.000000   0.000   0.000   0.000   0.000   0.000   0.000  120    0    0    0  GET /js/bootstrap.min.js HTTP/1.0
  120    0.148  0.001233  0.001843   0.000   0.001   0.003   0.004   0.011   0.012  120    0    0    0  GET /favicon.ico HTTP/1.1
  120    0.157  0.001308  0.001829   0.000   0.001   0.003   0.004   0.011   0.011  120    0    0    0  GET /js/bootstrap.min.js HTTP/1.1
  120    0.379  0.003158  0.002890   0.000   0.002   0.007   0.010   0.013   0.015  120    0    0    0  GET /js/jquery.min.js HTTP/1.1
  120    0.000  0.000000  0.000000   0.000   0.000   0.000   0.000   0.000   0.000  120    0    0    0  GET /favicon.ico HTTP/1.0
  120    0.000  0.000000  0.000000   0.000   0.000   0.000   0.000   0.000   0.000  120    0    0    0  GET /css/bootstrap-responsive.min.css HTTP/1.0
   67  116.697  1.741746  1.159447   0.020   1.760   2.999   3.000   3.001   3.001    0   42   25    0  POST /login HTTP/1.0
   67  116.706  1.741881  1.159099   0.020   1.760   2.999   2.999   3.001   3.001    0   42   25    0  POST /login HTTP/1.1
   35    0.857  0.024486  0.022147   0.000   0.026   0.040   0.085   0.096   0.096   35    0    0    0  GET /stars?keyword=%E5%86%85%E7%94%B0%E4%BF%AE%E5%B9%B3 HTTP/1.1
   35    0.977  0.027914  0.020538   0.000   0.031   0.049   0.062   0.077   0.077   35    0    0    0  GET /stars?keyword=%E3%82%A6%E3%83%BC%E3%82%BA HTTP/1.1
   34    0.867  0.025500  0.018035   0.000   0.028   0.044   0.059   0.071   0.071   34    0    0    0  GET /stars?keyword=%E5%8C%97%E6%B6%88%E9%98%B2%E7%BD%B2 HTTP/1.1
   32    0.731  0.022844  0.015575   0.000   0.025   0.040   0.050   0.052   0.052   32    0    0    0  GET /stars?keyword=%E8%BC%AA%E7%8A%B6%E7%94%B2%E7%8A%B6%E7%AD%8B HTTP/1.1

しかし、なかなか突破口が見いだせず、できるところからやっていく方針を取った。
アプリの改善を振り返ってみると、なにもしてねーなって感じがやばい。(何してたんだっけ…(・_・;))

  • isudaとisutarのfpmプロセスの調整
  • isudaとisutar間のhttpによるAPI呼び出しをなくし、DB接続とした
  • SQL改善
    • htmlifyのkeyword取り出しSQL
    • load_starのSQL
    • など
  • keywordのlengthを予め持つように変更
  • isudaとisutarの統合
    • 効果の検証ができず、結局マージはできなかった

反省

htmlifyの改善がなによりも効果がでることはわかっていた。
しかし、その改善についてのいい方法がすぐに思いつかなかったこともあり、
他のやれることを優先しすぎてしまったことが一番の反省点だ。

時間がない、大きな変更したら怖いという思いが強くなり、
どちらかというとやれることをきちんとやればいける、というディフェンシブな思考になってしまっていた気がする。

せっかくRedisやOpenrestyを準備していたが、
そのあたりを発揮せずにおわってしまい残念な感じではあった。
(ここは準備不足ポイントでもあった)

根本の改善に勇気を持って切り込む"Courage"を次は発揮したい。

反省会の炙りしめ鯖うまかった。

tabelog.com

最後に

反省点は多かったものの、準備期間も含めてこの1ヶ月とても楽しかったし、
また自分の未熟さを実感できてとてもよかった。

今まで、競技プログラミングなどもしたこともなく、
技術面で「競う」ということはほとんどしたことがなかった。

この敗北で、技術をきちんと理解し追求していきたいという想いが湧いてきた。
ISUCON主催者ありがとうございました。

社内システム開発からパブリッククラウドの会社へジョインします

異動

本日、2016年7月29日をもって、新卒から3年4ヶ月働いてきた部署が最後となり、8月1日から異動(出向)する。
社内転職制度を使って、自らの希望でパブリッククラウド事業の会社へジョインすることになった。
(新規事業を行う部署へ異動となり、そこから別会社へ出向という扱い)
グループ内の異動ではあるが、違う会社・事業で、職種も変わるので、今の部署でやってきたことをまとめて残しておこうと思う。

私は通信会社のネットワーク運用部隊に所属している(いた)。
ネットワーク運用部隊なのだが、私の部署はネットワーク運用を自動化したり運用を楽にするためのシステム開発を担うところで、下記のような仕事をしてきた。

1. ベンダーコントロールという仕事

システム開発にはうちでは外注物も内製物(後述)もある。
業務の都合上、システムの種類によってはSIベンダーへ発注をして作ることがあった。
ベンダーコントロールなんて言ったりするが、発注でのシステム開発の業務では下記のようなことをしてきた。

  • 要求仕様の検討
  • 見積もり依頼と価格交渉
  • 発注、スケジュール調整
  • 社内での業務調整
  • 受入試験、検収
  • 運用

仕事のほとんどは、社内外の人との調整(コミュニケーション)だ。
エンジニアとしては一見つまらなそうな仕事にみえるかもしれない。
しかし、この仕事から様々なコミュニケーションを学び、それはいろんな場面で役に立っている。
例えばだが、以下の様なコミュニケーションがあったりした。

  • 要求を他者にしっかり、わかりやすく伝える
  • 仕様や価格についての折衝をする
  • システムの利用部門との業務調整をする
  • 作業の手順について精査し指摘する
  • ミスなど良くないことが起きた際には、今後の対策はどうするか相手側に考えさせるよう導く
  • 場合によっては厳しく叱ることもする(感情的に怒るわけではない)

特に価格の折衝などは、SIerや購買部と激しく激突することもあり今でもとても印象に残っている。
こういった業務はビジネスマンとしてとても大事なことを学んだと思うし、内製での開発業務でもとても活きてきている。

外注はいいけど・・・

社内リソースが少なくても同時並行でいろんなシステムの開発ができるし外注はいい。
一方で外注開発について、もどかしさや非効率さなどもたくさん経験してきた。

まず、なにをやるにもお金と時間がかかることだ。
一度納品されてしまったものについて、なんらかの改修をしたい場合、
その改修規模を問わず、見積もり→発注→開発・改修→納品のプロセスを通さなければならない。
if文を1行追加するだけだろ…って思うようなものでも数百万で数週間かかることだってあった。

そして、プロセスの効率化が難しいことだ。
ベンダーが開発したシステムをリリースするには、発注側の会社に度々きてリリース作業を行う。
勝手に発注側のシステムをアップデートすることはありえないので、必ずリリース作業には社員が立ち会わなければいけない。
そのとき、リリース作業が自動化されていないことも多く(発注時の要求によってもちろん異なる)、
何時間もかけて数十台のサーバにデプロイしたりしなければいけなかったりするので大変だ。

これは当たり前だがとても効率が悪いし時間の無駄だ。
だがこれを改善しようと思うとまたお金がかかるわけである。
扱っているシステムが、業務システムなのでアップデートの頻度がおおくないこともあるので、
はじめからデプロイの自動化などを要件にいれることは少ないのである。

これらはSIの開発をディスっているわけではない。(要求も悪いのはわかる。)
これは仕方ないこととして、そのメリット・デメリットをきちんと理解した上で選択、要求をしなれけばいけないということだ。

2. 内製開発の仕事

外注開発とは別にシステムの内製での開発業務も多くおこなってきた。
社内的には外注開発から内製開発に徐々に切り替えの最中であった。
ちなみに開発言語はRubyRailsやPadrino)やPHPFuelPHP)なんか使っていた。

業務システムの他にもメールサーバやリバースプロキシサーバなど基盤システムも構築してきた。
2015年の振り返りブログに雑だが少し書いていた。

mosuke5.hateblo.jp

開発組織の改善活動

また、開発組織を改善するための活動をおおく行ってきた。
どこの組織でもある問題だと思うが、うちもまた「属人化」「秘伝のタレ」などといった類の悩みをたくさん抱えていた。

うちはソフトウェア企業ではないし、システムを外注で作る部署も多い。
そのため、新卒や異動してくる人などがソフトウェアエンジニア思考の人ばかりではない。というかむしろ少数派。
だからこそ、よりいっそう「属人化」「秘伝のタレ」が弊害となる。
わかりやすいところでいうと下記のようなことをやったりして開発組織の改善をしてきた。

  • gitlabを使ったgithub-flowの導入。レビュー必須化
  • Ansibleを使ったインフラ環境のコード化、構築自動化
  • またそういったツールの導入だけでなく講師としてワークショップの実施やサポート活動
  • 部署内の開発ルールの策定
  • 最低限身につけてほしいスキルや知識を習得できる環境や研修の準備

ツールの導入や普及、組織改善活動について次の2つがとても重要だったと思う。

  1. キーパーソンを見方につける。
  2. ハンズオンを行う。サポートを手厚くする。

どんなにいい試みをやっても、独断で行ってしまうと「勝手にやったことだよね?」ってやっぱり思われてしまう。
また、その試みを広めるのに苦労する。
試みに対して理解してくれる上の人、キーパーソンを見方につけて働くことがとても有効的だった。

そして、ツール類はとくにそうだが、紹介したりするだけじゃなくて、
ハンズオン会をやったりサポートをし「軌道にのせる」ところまでやったのがとてもよかった。
サポートがないと、気が付くと昔のやりかたにもどってしまっていた、なんてこともあった。

3. データセンター、ネットワークの仕事

データセンター系

サーバ環境はオンプレだった。
また、専任のサーバ・インフラ管理者がいるわけではなかったので、
データセンターへのサーバラックの立架工事やサーバラッキング、配線などそういったことも業務の1つだった。
データセンタ系業務とそれで身につけたことなどは下記。

  • データセンターへのサーバラックの立架工事やサーバラッキング、配線をやった
    • ラックの立架工事や電源工事は当たり前だが外注
    • 工事の監督はさんざんやった
    • サーバのラッキングやLANケーブルの敷設は自前でもたくさんやった
    • LANケーブル作るのはだいぶこなれた
    • でもやっぱりプロの配線は神
  • 安全に工事するための知恵をたくさん身につけた
  • 電源工事などに備え、電気的な知識を身につけた
  • openstack(プライベートクラウド)の検証などもした
ネットワーク系

バックボーンのネットワークは範囲外ではあるが、
システム内のネットワーク設計・構築・運用は自分たちの仕事だった。

そういう組織体系が業務的によかったかどうかはわからないけど、
現代では特に触れる機会が少ないネットワークについて理解を深められたのはとてもプラスになっている。
下記あたりは自前でやってきた。

  • システム内のネットワークの設計
  • L2スイッチ、L3スイッチの設定
    • VLANとかNAT、ACLとか
  • NW機器が故障した際の交換とか設定投入

ネットワークは専門ではないけれど、オンプレでやっているとネットワーク系の仕事をやることや、
他部署とネットワークの話をしなければいけないことが多い。
ネットワークの知識は仮想サーバを構築するときなどにも役に立つし、ソフトウェア開発でも何かと役に立っている。
ちょうど最近、システムが調子悪い原因が光ファイバーの不良ということを発見できてとてもスッキリした。

4. その他

その他にあったことを雑にまとめる

  • たくさん出張にいった
    • 大阪、北陸、名古屋、広島、四国など
  • 社内での業務改善コンテストで賞をとった
  • 新卒の面倒をみたりした
  • インターン生も毎年きて面倒をみた
  • 採用リクルータをやって就活生とたくさん出会った
  • マリオカート大会企画した
  • 勤務地が変更になったりした

最後に

ほんとうに多岐にわたる仕事をさせてもらい、視野が広がった3年間だった。
アプリケーション開発しか知らなかった学生時代を振り返ると驚くほどの成長をしたと思う。

部署や上司、メンバーへ、本当に感謝です(^人^)

次は、パブリッククラウドの会社に行く。
パブリッククラウドを構築し運用するところなので、AWSGCPが敵…)

会社ではオンプレを使っていたし、またプライベートクラウドの構築の検証にも携わった。
規模感や組織構造によるのはわかっているが、どうもシステムを維持することにばかり時間を費やし、本来やるべきシステム開発による問題解決になかなかいたらなかった感じはあった。
一方、趣味開発ではAWSやHerokuなどのクラウドを使っていたので、本来やるべき問題解決に集中できることの価値を感じていた。
そういった経験から、パブリッククラウドをもっと多くの人が活用してシステム開発の本質により注力できるように、と思うようになった。

最後に…
この3年間で社内の仕事の質がかわった瞬間を目の当たりにした。
外注も内製もやってきたと書いたが、はじめは外注が多かったが徐々に内製開発の比率が増えてきた。
それに伴って、社員が行う仕事の質や求められるスキルが変化していったのを感じた。
きっと、次の3年間もなんらかで変化が起こるはずで、振り落とされないよう頑張りたい。

※次のところ英語話さなきゃいけなくてほんとにヤバイ・・・

とてもながめのいいオフィスでした。