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

Goldstine研究所

mosuke5's tech blog

ブログ移転しました。5秒後にリダイレクトします。

(備忘録) 運用サイトのドメインとサーバ

完全備忘録。自分でもわからなくなってきたので。 公開すればきっと更新もする。

docs.google.com

万能じゃない。オブジェクトストレージの仕組みと利用を正しく理解する

1.はじめに

Amazon S3をはじめとして、オブジェクトストレージが身近になってきています。
クラウドベンダーはオブジェクトストレージサービスを提供しています。

ですが、オブジェクトストレージをストレージの魔法として理解されているケースも多いように感じます。
原点に振り返ってそもそもオブジェクトストレージとはなんなのか。
どんな特徴を持っているストレージなのか。
気になってまとめました。

2.オブジェクトストレージとは

オブジェクトストレージとは一言で言うと、
「オブジェクト単位(ファイル単位)で出し入れのできる、ネットワークストレージ」です。

オブジェクトストレージでは直接にストレージ上のファイルをRead/Writeすることはできません。
いうなれば、FTPサーバに近い存在と言えます。

今やクラウド上のストレージの代名詞として扱われるオブジェクトストレージですが、
実はファイルの出し入れしかできないストレージなのです!?!?

3.特徴

では、そんな出し入れしかできないFTPサーバに似たオブジェクトストレージですが、
その本当の特徴はどこにあるのでしょうか。

特徴1: ディレクリ構造の排除

1つ目の特徴としては、ディレクトリ構造でファイルを管理しないことです。
ディレクトリ構造は、もしストレージサーバのハードディスク容量がいっぱいになり、
ファイルを別のディスクに移動する場合、そのディレクトリパスも変更しなければいけません。
クラウドサービスのようなたくさんのユーザが利用し拡張性の求められる場面では、ディレクトリ構造は適さないのです。

そこで、オブジェクトストレージではディレクトリ構造ではなく、階層のないフラットな関係でファイルが保存されます。
すべてのファイルにIDが付与され、そのIDがどこに保管されているか別で管理する仕組みとなっています。

特徴2: 分散保存

2つ目の特徴は「分散保存」です。
オブジェクトストレージでは、ファイルを分散保存するアーキテクチャによって、
ファイルの冗長化と大量のファイルへのアクセスさばくことを可能にしています。
詳しくは次の「オブジェクトストレージのアーキテクチャ」の項目でご紹介します。

特徴3: アプリケーションからの利用を意識

3つ目の特徴はアプリケーションでの利用を強く意識していることです。
この項目は製品によって異なる部分もありますが、主な点を3つあげます。

(1)メタ情報管理

従来のファイルシステムでのファイルへのメタ情報は、ファイルのサイズや更新日付などが一般的でした。
オブジェクトストレージでは更にファイルの有効期限などを設定することができ、インフラ管理を容易にします。

(2)HTTPプロトコルを使ったインターフェイス

オブジェクトストレージでは、ファイルのアップロード、ダウンロードなどすべての操作はHTTPプロトコルを利用します。
HTTPのような汎用的なプロトコルを採用することにより、サーバからはもちろん、モバイル端末など幅広いデバイスから利用が可能です。

(3)Web公開機能

更には、保存したオブジェクトに対してURLを割り当てて公開することもできます。
静的なWebサイトの公開や、cssJavaScript、画像ファイルなどを直接オブジェクトストレージへ取得しにいくこともできます。

4.オブジェクトストレージのアーキテクチャ

オブジェクトストレージとひとまとめにいっても、製品によってその実現方法は様々で異なります。
しかし、ここでは一例として利用されるアーキテクチャについて紹介します。

※ここで紹介するアーキテクチャがオブジェクトストレージのすべてのアーキテクチャを表すものではありません。また、わかりやすくするためかなり簡略化して記載しています。

アーキテクチャ

大きく分けて、プロキシノードとストレージノードの2つによって構成されています。
ファイルをアップロードする時(保存する時)、プロキシノードは受け取ったファイルを、
バックエンドにあるストレージノードに保存するのですが、この際に複数のストレージノードに対してファイルを保存します。
これによって、冗長化を実現しています。
実は、各ストレージノードではRAIDは行わず、複数のノードに対して保存することで冗長化をはかっています。

一方、ファイルをダウンロードときは、複数のノードに保存されているファイルのうちどれか1つを選びます。
これによって大量のファイルへのアクセスの負荷分散も実現しています。

ファイルアップロード

f:id:mosuke5:20170318164020j:plain:w600

ファイルダウンロード

f:id:mosuke5:20170318164028j:plain:w600

オブジェクトの配置情報の管理

ファイルをアップロードする際に、プロキシノードは複数のノードに保存すると説明しました。
例えば10台のストレージノードがあり、そのうち3台に保存したとしたとします。
取り出す際にどのノードに対象のファイルがあるかわからなくなってしまうので管理が必要です。

そのため、すごく簡略化すると下記のような対応表を作って管理します。
あるファイルがどこに保存されているのか記述された対応表です。

ファイル名1 ファイル名2 ファイル名3
保存場所1 1 2 5
保存場所2 5 3 8
保存場所3 9 10 10

また、オブジェクトストレージは拡張が優れている点が特徴と述べました。
ストレージノードが追加されることは頻繁に行われます。
その際には、リバランスと呼ばれる処理が行われ、追加されたノードを含めてオブジェクトの再配置が行われるようです。

Eventual Consistency

複数のストレージノードに対してファイルを保存しているわけですが、
例えばあるストレージノードが障害中に、ファイルの更新があった場合はどうなるのでしょうか。

障害があったストレージノードが復旧すると、そのノードだけファイルが古い状態となります。
この状態でファイルの取得を行うと、古いファイルを取得してしまう可能性があります。

そのため、オブジェクトストレージでは定期的に同期の処理が行われ、正しい状態へもどす機能があります。
この機能によりしばらく時間が立つと全体の整合性がとれた状態となります。
このことを「Eventual Consistency」と呼びます。
直訳で考えると「最終的には整合性があるよ」といったことろでしょうか。

Amazon S3でもデータの整合性について記述されています。
Amazon S3 のデータ整合性モデル

Erasure Coding

Erasure Codingとはデータの保存方法のことだ。
上の例ではレプリケーション的なデータの複製保存をしている。
3箇所に分散して保存すると、単純にストレージの利用効率は1/3です。
その効率をあげるためにErasure Codingを採用することがある。

ここで詳細を説明するには重たすぎるので、ぐぐってほしい。

www.jdsf.gr.jp

5.オブジェクトストレージの向き不向き

上記にみてきた特徴を持つオブジェクトストレージですが、その最適な利用用途はなんだろうか。
IDCFのサイトにいい感じにまとまった用途が図式されていたので、スキップしちゃいます笑

www.idcf.jp

6.オブジェクトストレージの勘違いしがちなユースケース

(1)ログのオブジェクトストレージへの保存するケース

よくFluentdを使ってS3へのログの保存が紹介されます。
この利用方法はとてもまっとうであり、正しい使い方といえます。

blog.serverworks.co.jp

ですが、たまにリアルタイムでのログ保存と勘違いしている話をききます。
上で紹介してきたように、オブジェクトストレージはファイルの出し入れしかできません。
リアルタイムのログを1行ずつオブジェクトストレージに書き込むには、その都度ファイルを入れ替えるしかありません。

そのため、オブジェクトストレージを利用したログ管理はリアルタイムなものではなく、
例えばログファイルがローテーションされるたびにアップロードするなどの利用になる点は抑えておきましょう。

また、クラウド環境ではサーバは負荷に応じて増えたり減ったりすることが日常的です。
Fluentdではサーバのシャットダウンシグナルを受け取った時に、ログを出力する機能があるので、
クラウド環境でもオブジェクトストレージを使ってログ管理を行うことは可能です。

(2)サーバにオブジェクトストレージをマウントするケース

オブジェクトストレージをサーバにマウントして利用するケースも多く見受けられます。

qiita.com

オブジェクトストレージでは階層構造はなく、フラットなファイル管理を行います。
またファイルの操作はすべてHTTPで行います。
サーバにマウントすると、一見通常のファイルシステムのように見えてしまいますが、見せかけだけです。
その点を理解して利用するようにしましょう。

追記メモ (2017/03/28)

  • FTPにも近いが、今は忘れられつつあるWebDavが似たような実装
  • 突き詰めれば、従来ファイルシステムもR/Wしかできないのは同じ。ブロックサイズの違い。
  • いつになってもR/Wしかできないのです。

test

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

先日、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にいってきたメモ

はじめに

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の構築・運用について考える。
実際に、とあるクラウドで分散環境の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年振り返り

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

そんじゃーね。

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

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

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の存在は見逃せない気がしてくる。