tech.guitarrapc.cóm

Technical updates

CDNに新しい風を吹き込むCDN - Fastly社に行ってみた

最近 CDN で一番勢いがあるのは?と聞かれた時に Fastly 社の名前が上がってくることが多いのではないでしょうか。

3/15~3/18 (PST -8:00) にサンフランシスコで開催される Game Developers Conference 2016 (GDC) に参加しているのですが、Fastly Japan 営業の Mio Matsuda さんにFastly 本社を訪問する機会をいただいたので訪問レポートをしたいと思います。

Fastly 様は GDC でもブースをお持ちなので、この記事で気になったGDCに参加している方はぜひ訪問してみてください。

Game Developers Conference (GDC)

目次

Fastly 様紹介

今回訪問させていただいたのは、Fastly様です。

www.fastly.com

Fstly 様といえば、オープンソースベースのオープンなプラットフォームとしてVarnish を採用していることが有名だと思います。

github.com

github.com

CDNにVarnish を基盤技術として採用することで、従来のCDN では難しかったソフトウェアによるキャッシュの制御を極めて高度に行うことができるのが Fastly の特徴です。ただVarnish を採用するだけでなく、Varnish Configuration Language (VCL) を用いたキャッシュの細やかなカスタマイズ制御もできるのは他のCDNにない素晴らしい特徴といえます。

VCL を使った細かなキャッシュ制御

他にも、150ms 以内のインスタントパージをキャッシュ全体以外にもサロゲートキー指定や URL指定で実行できます。これらの制御がすべてAPIでも可能なため、これまでのCDNでキャッシュ制御が困難だったコンテンツもキャッシュ対象にできる可能性があるなど、従来のCDNに風穴をあけ猛烈な勢いで成長しています。

apiguy.tokyo

例えば、WordPress コンテンツのようなCMSは「頻繁に更新すかもしれないししないかもしれない、けれども更新後の配信はキャッシュに載せておきたい。」といい、何かのイベントをベースに配信するという特徴があります。これまでのCDNではキャッシュパージも遅くCDNを画像など限定的にしか使うことが難しい面がありました。しかしFastlyを用いることで、更新時にAPIで 150ms 以内に古いキャッシュをクリアして新しい記事内容を配信、キャッシュできます。しかもワンクリックでインストールできるプラグインである Purgelyもあります。動的コンテンツの中でも、CMSや販売サイトなどのイベントベースでのコンテンツがキャッシュできるのはかなり強いでしょう。

CondeNast の Purgely はWired.com で実装されていて、Wired.com はWordpress を使っているサイトの中でも世界最大規模のアクセスを誇るそうです。すでに実績のあるプラグインで導入も容易なので、かなりいい感じです。

github.com

もちろん、設定のバージョニングにも対応している他、そのアクティブ/非アクティブもすさまじく早く、変更をアクティブにする前に事前にテストすることもできます。CDNをポータルだけではなくAPIからも完全に扱える、それがFastlyです。

無料アカウントでも $50 の課金までは課金なしで利用できます。日本でも 1GBあたり $0.19で利用できるので、ほとんどのテストケースは無料になるかと思います。実際私が会社で導入した時も、無料アカウントから検証して、スムーズに移行できました。

www.fastly.com

尊敬している日本開発者も入社エントリを書かれており、実際にFastly を使っている身としてもとても気になるので今回の訪問を本当に楽しみにしていました。

weblog.bulknews.net

plex.hatenablog.com

所在地

さて、Fastly Japanとしては、新丸ビルにサテライトオフィスをお持ちですが、今回は本社のある 米国カリフォルニア州サンフランシスコ SOUTH PARK にお伺いしています。

当日はあいにくの雨*1でしたが、GDC の会場もあるユニオンスクエア近辺から徒歩20分程度歩くだけとかなり近くに位置しています。

Fastly 社の入っているビルの外観です。年代が経っているビルとのことですが、シックな外観から中に入ると雰囲気があります。

中に入って3F へ。

現在、サンフランシスコのスタートアップはこの近辺に多く所在しているとのことです。先の記事にあった Docker社も先日までFastly社の隣を借りていたとのことでした。(扉に張り紙と、奥にロゴがありました)

オフィスの雰囲気

あいにくの日曜日で、オフィスに勤務中の方はいらっしゃらいませんでした。Welcome と書かれた受付から中にお邪魔します。

Mioさんに、オフィスツアーをしていただきました。

受付から入ってすぐの壁には、Fastlyにジョインされた方の写真が飾ってあります。従業員を大事にされている印象が伝わってきますね。どの社員も建物の煉瓦を背景にされており一体感があります。

反対側には、外来の方が待つスペースがあり、Fastly Red のソファがおいてあります。伺ったところによると、Fastlyはブランドカラーを大事にされており、様々な調度品やノベルティもブランドイメージを損なわないように気を払っていらっしゃるとのことでした。

社内にある調度品もFastlyのイメージカラーで統一されています。

オフィスは、扉が無いオープンスペースで広々と開放感があります。

3F と2F の2フロアが中の階段でつながっているのですが、大きな階段ですぐに行き来できるので、フロアがわかれていてもつながっている感じが損なわれていないのがすごいです。

天井からつりさげられた大型のディスプレイには、2015年に Fastly を利用開始された企業の一覧がディスプレイで表示されています。1ページでは収まらず複数ページにわたっており、Fastly社の勢いを感じます。

Wifi や電源も完備されており、席を決めずフリーアドレスで仕事をすることもできるようになっているそうです。また、リモートワーカーも多く世界各国の従業員の多くは自宅から仕事をされたりしているそうです。こうすることで、緊急時にも素早く対応することもできているとのことでした。

リモートワークといえば、コミュニケーションがよくネックになりますが、Fastly 社では Zoom を使うことでうまくやっているとのことでした。Zoomは Treasure Data様も利用されているとのことなので、気になりますね。

zoom.us

dev.classmethod.jp

Fastlyの開発はRuby を活用しており、社内のほとんどはMacユーザーとのことです。ごく一部だけ Windows を使っており、非常にレアとのこと。残念ながら開発者の方は出社されていなかったため、詳細をお伺いできなかったのですが機会があれば開発環境も伺ってみたいですね。中には、スタンディングで仕事ができる器具を机に装着されている方もおりかなり自由な感じでした。

会議室も10以上あり、その命名はFastly だけに「早さ」に関わるものとのこと。ちらっと見かけたのもの以外にもまだまだあります。

数多くの会議室がありますが、その利用や予定は会議室の内外にあるタブレットから操作可能になっており非常に効率的でした。*2会議室管理はかなり困難を伴うことが多いのでも、このシステム紹介してほしいですね!

キッチンスペース

おわりにキッチンスペースも見せていただいたのでご紹介します。

会議室やオフィススペースの他にもキッチンもあります。最近のサインフランシスコのスタートアップではキッチンがあるかどうか、ランチが提供されるかも1つの就職のキーになっているとのこと。Fastly社でも、毎週定期的ににランチがふるまわれるそうです。ランチのある日には普段よりも多くの従業員が集まられるとのことで、どの国もランチは一緒ですね。

3Fには中庭もあり、天気のいい日には外で仕事をされたり、ランチを召し上がることもあるそうです。

キッチンスペースには、生ビールのサーバー以外にもワインさーバーまであります。オーストラリアにもビールサーバーが社内にある会社が多いですが、ワインサーバーまであるのは初めてみました。

壁にはこれまで作られてきた Fastly Tシャツもあります。よく会場で着てらっしゃるのを見るやつですね。

キッチン奥には、ペット用のエサ入れもあります。Fastly HPのトップを飾るパグのゴルド君もここで一緒に食べてるそうです。

↓ゴルド君

他にもおやつも提供されており、ものすごい山です。

お土産に m&m もらっちゃいました

さいごに

いかがでしたでしょうか?とても面白く、社内見学ツアーに1時間以上かけていただきました。多くの点で興味深く、学ぶものがあり、何よりも急成長するスタートアップの勢いを感じました。

ご対応いただいた、Mio Matsuda さん、Fastlyの皆様、本当にありがとうございました!

EXITとか、何気ないところがかっこいいです。

*1:ここ 2, 3年は雨が少なく困っていたそうです

*2:緑のパネルに予定などが表示されます

Windows Management Framework 5.0 RTM (PowerShell 5.0 RTM) が再リリースされました

おかえりなさい。

ということで、リリースされて一週間で撤収された WMF 5.0 (PowerShell 5.0) RTM でしたが、ようやくバグ修正が終わり再リリースされました。

Download Windows Management Framework 5.0 (Superceeded by WMF 5.1 RTM version: http://aka.ms/wmf5download) from Official Microsoft Download Center

目次

回収理由

以前も説明しましたが、$PSModulePath が WMF5.0 のインストール時に上書かれる問題があったためです。

https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11148471-bug-wmf5-rtm-psmodulepathwindowsserver.uservoice.com

前回との違い

ほぼアリマセン。

  • The KB numbers of these packages (KB3134758, KB3134759, and KB3134760) are different than previously released WMF 5.0 RTM packages (KB3094174, KB3094175, and KB3094176)
  • These packages have fixes only for the PSModulePath issue compared to the previously released WMF 5.0 RTM packages

ということで、インストールKB が変わりました。 そして、修正されたのは PSModulePath 問題だけです。

Operating System アーキテクチャ インストールパッケージ名
Windows Server 2012 R2 x64 Win8.1AndW2K12R2-KB3134758-x64.msu
Windows Server 2012 x64 W2K12-KB3134759-x64.msu
Windows Server 2008 R2 x64 Win7AndW2K8R2-KB3134760-x64.msu
Windows 8.1 x64 Win8.1AndW2K12R2-KB3134758-x64.msu
Windows 8.1 x86 Win8.1-KB3134758-x86.msu
Windows 7 SP1 x64 Win7AndW2K8R2-KB3134760-x64.msu
Windows 7 SP1 x86 Win7-KB3134760-x86.msu

ということは、New-ScheduledTaskTrigger 問題残ってるかもですが..。

インストール時の注意

You must uninstall previously released WMF 5.0 RTM (KB3094174, KB3094175, and KB3094176) packages.

以前の WMF5.0 はアンインストールしてください。

Windows 10 や Windows Server 2016TP への影響

Windows 10 and Windows Server 2016 Technical Previews builds are not impacted by the above mentioned PSModulePath issue. This issue was only impacting down-level systems where WMF 5.0 RTM can be installed.

ありません。あくまでも、Windows Server 2012R2 や Windows 8.1 などのダウンレベルOS のみです。

BuildInsider での詳細機能紹介

さて、PowerShell v5 がリリースされる。ということで、Build Insider で記事を書いております。

www.buildinsider.net

当初、2015年12月22日リリースだったこともあり、早々に記事を用意していたのですがその後回収されてしまったので 2ヶ月近くオクラ入りになってました。

さて、今回の記事を書くにあたって、編集者の @isshiki様と新しい試みを試しました。GitHub での記事の編集作業です。

www.buildinsider.net

コミット履歴で まさかの revert があるように、当初かなりやり方の意識に相違があったため戸惑いましたが、結果としては非常に楽になりました。これもすべて、@isshiki 様が良くしようという努力をしてくださったからです。今回の試みは、記事執筆、推敲、進捗どうですかなどの様々な面で Build Insider の記事執筆時に感じていた辛さが軽減されました。このスタイルを望む人にとって標準になると嬉しいですね。

PowerShell Team の Twitter アカウント

PowrShell Team の Twitter アカウントが @PowerShell_Team 開設されました。ここでもBuidInsiderの記事を紹介してあります。海外から見ると日本語記事は相当とっつきにくいのですが、Translator なりで参考になればいいですね。

まとめ

ぜひ WMF5.0 をお楽しみください!

tech.guitarrapc.com

Remote Desktop Web Service を AWS Elastic Load Balancing で冗長化する

プライベートネットワークにあるリソースへのリモートアクセスするにあたりどんな方法が一般的でしょうか。

10年前はVPN全盛で、社外からのアクセスに IPSec や PPTP などが用いられていたように思います。しかし、現在リモートアクセスを提供するなら、Remote Desktop Service を利用することが多いでしょう。幾つか理由がありますが、SSL でのアクセスは制御しやすく便利なものです。

リモート デスクトップ サービスの概要 | Microsoft Learn

さて、便利な Remote Desktop Service ですが、サーバーを持つと当然の如く1つのエンドポイントに対して冗長化されていることが期待されます。今回は、AWS Elastic Load Balancing で、透過的に社外からの社内リソースアクセスを提供してみましょう。

目次

環境設計

Remote Desktop Service (以下 RD Service) に関して、以下の環境を考えましょう。

ポイント 概要
アクセスURL rdweb.example.com というレコードで External ELB の Aレコード Alias を公開しておきます。ユーザーがリモートデスクトップするために利用するアドレスはこれです。
MultiAZ RD Service を EC2 に構築する際は、MultiAZ になるようにしておきます。
ELB ELB は、ぶら下がったRD Service のEC2の死活監視とバランシングを行う役割です。外からのエンドポイントは ELB 一本になるので、Internet facing で作成します。また、リクエストをバックエンドにパススルーするため、SSLではなく TCP 443 で設定します。
RD Service RD Service は、EIP を付与して、Route53 で公開しておきます。

ざっくりと以下の構成ですね。

接続方式

一言に Remote Desktop といっても Remote Desktop Service で提供する方法が複数あります。

  1. Remote Desktop Web Access (RD Web アクセス)
  2. Remote Desktop Gateway (RD ゲートウェイ)

今回紹介するのは、RD Web アクセス を用いた Remote Desktop とその冗長化です。RD ゲートウェイは、ELB を用いた冗長化ができないためご注意ください。

説明の省略

RDS サーバーを立ててEIPを振るのは省略します。DSC でも使って楽に構築してください。

www.powershellgallery.com

www.powershellgallery.com

www.powershellgallery.com

構築

とりあえずさくっと構築しましょう。

EC2 は立ててあるという前提で、ELB と Route53 のレコードをさくっと作ります。

ELB の作成

Internet facing で、ELB を作成してください。Lister は TCP 443 で Load Balancer Protocol/Instance Protocol を設定します。

これが構成の要です。くれぐれも SSL や HTTPS にしないでください。SSL のターミネートも持っての他です。

Ping も TCP 443です。

作成したら、続いて Route53 です。

Route53

ELB の A Record Alias、あるいは CNAME を作成します。(ここでは仮に guitarrapc.com のドメインとします。)

合わせて、RD Service のサーバー2つに付与したEIP で Aレコードも作っておきます。

RD Web への RemoteDesktop の公開

RD Web から内部リソースにリモートさせるため、Remote Desktop を Remote Appとして公開します。

こんな感じで RD Web で表示されればok です。

Remote Desktop Gateway が本構成では使えないように、RD Web からの リモートデスクトップはできませんので使わないようにします。

接続

さて、あとは繋いでみましょう。Private LAN ではなく、WAN 越しに Route53 で作成した rdweb.expample.com にアクセスしてみます。

Remote Desktop 接続をクリックしてダウンロードしたら

ドメインユーザーの認証を入れます。

無事に RemoteApp の認証が通れば、RD Webサーバーとつながったというトースト通知がきます。

あとは、アクセス先のサーバーを指定して、ログインしてみます。今回は適当に RD Webのサーバーにアクセスします。

サーバーにログインできましたね。

もちろん Server1 とServer2 がラウンドロビンされますし、Server1接続できないように Stop するとServer2 につながります。

ELB で冗長化されると生存監視を任せられるので楽ちんです。

まとめ

今回は、ELB を用いることでRD Web サーバーの死活監視、冗長化を行いました。個別のサーバーに直接アクセスよりも圧倒的にいいです。ただ、ELBの性質上、アクセスのたびにアクセスが分散されることがあります。その時は接続処理を繰り返せば問題ありません。ここで紹介した内容は全部SDK や PowerShell でさくっと自動化できますし、Cloud Formation を使うのもいいでしょう。

同じ要領で、ADFS の Web Application Proxy も冗長化したり、ADFS 自体も冗長化できるのでお試しください。基本的には、AWSだけではなく環境選ばず、Azure や GCP でも同様に構成できます。

RD Gateway が ELB と相性悪く、接続が確立できたりできなかったりするので、RD Web は間違いないことから推奨しておきます。

Unity Cloud Build を API で操作しよう

Unity のビルドといえば、長らく Mac + Jenkins などのCIツールという印象でした。昨年、Unity Cloud Build の存在を知ってはいたものの、いまいちという印象で回避してきました。

改めて触ってみると git連携、ビルド状況の把握、ユーザーのダウンロードフロー、コントリビュートなど機能がそろっており、非常に使いやすいことがわかりまます。

今回は Unity Cloud Build を API経由で触ってみましょう。

なぜ API が必要なのか

Unityは Beta リリース や Patch リリースが頻繁で週1回のペースで更新されます。更に、対象プラットフォームに合わせて多くのビルド構成が必要になります。

特にアセットとしては様々な環境に対応するため、Unityバージョン × プラットフォーム 分だけビルドを回す必要があります。

手作業で、ビルドターゲットをポチポチ作るのは10個までは我慢できてもそれ以上はむりでしょう。そこで、API を使って自動構成、自動ビルド、任意のビルド、ChatOps を実現することで人間の生活を送れます。

API Document

Unity Cloud Build API は Swagger ベースになっています。

Unity Cloud Build API

Swagger は強力無比なAPI基盤です。ここから直接APIを叩くこともできますし curl の実行サンプル、レスポンスJSONサンプルまで表示されています。

Unity Cloud Build の API Document 最高ですね。Visual Studio Team Service もこれぐらいAPIをわかりやすく公開してほしいものです。

クライアント生成

API を叩くのにクライアント生成する時代は、Swagger によって劇的に変化します。

Swagger でAPIを構成すると、そのAPI構成が json で自動的に吐き出されます。

クライアント URL : https://build-api.cloud.unity3d.com/api/v1/api.json

利用者は、そのjson を Swagger のクライアントコード生成に投げつけることで、クライアントコードが自動生成されるのです。もはや書かなくていいに等しいぐらいい十分なものができます。

https://generator.swagger.io/

Generator ページのPOST /gen/clients/{language} に以下を入れることで クラインとコードが生成され、レスポンスの link からダウンロードできるようになります。

language:csharp
body:
{
  "spec": {},
  "options": {},
  "swaggerUrl": "https://build-api.cloud.unity3d.com/api/v1/api.json",
  "securityDefinition": {
    "description": "string",
    "type": "string"
  }
}

あとは、生成されたコードをソースに埋めて、生成コードが依存している次の NuGet Package をプロジェクトにいれるだけです。

Install-Package RestSharp
Install-Package Newtonsoft.Json
Base64Encode メソッドの追加

とはいえ、実はクライアントコード生成が腐っているため、Base64Encode() メソッドが存在しません。追加してあげましょう。

gist.github.com

static メソッドとして追加して、各クラスで using static してあげるのが素早く簡潔な対応です。

using System;
using System.IO;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;
using RestSharp;
using UnityCloudBuildApi.IO.Swagger.Client;
using UnityCloudBuildApi.IO.Swagger.Model;
using static UnityCloudBuildApi.Encode;

namespace UnityCloudBuildApi.IO.Swagger.Api
{
    ....
}

これらの対応 + サンプルを足した UnityCloudbuildApi を GitHub で公開しています。

github.com

では、作成したクライアントコードを使って、API 経由で Unity Cloud Build を操作してみましょう。

事前準備

認証

API を叩くためには、Unity Cloud Build の認証を取る必要があります。

Unity Cloud Build のマイページにアクセスするとAPI Key を取得できます。

https://build.cloud.unity3d.com/login/me/

パス一覧

ドキュメントが Swagger とともに公開されているのでみてみるといいでしょう。

Unity Cloud Build

API 実行

サンプルプロジェクトをソリューションにいれておきました。

LinqPad で見てみましょう。

gist.github.com

config 生成

Api に仕込む認証を config にセットして使いまわします。併せて OrganizationId や 対象の既存プロジェクトId もあるなら用意してもいいでしょう。

gist.github.com

プロジェクト API

各Api処理がそれぞれ用意されています。ProjectsApi(config) から、プロジェクトに関するApiが自在に叩けます。

gist.github.com

プロジェクト追加は、GUI の追加処理とほぼ同じです。直感的に扱えるので困ることもないでしょう。

ビルドターゲット API

ビルドターゲット、つまりターゲットプラットフォームやUnityバージョンの組み合わせです。最も増えるのでAPIで操作したい候補ですね。

gist.github.com

ビルド API

ビルドを実行したりするにはこの API を使います。ビルド状態の取得から、開始、停止まで自由に行えるので非常にいい感じです。

gist.github.com

まとめ

その他にも User や Organization、Billing、Config のAPIもありますが紹介はここまでにします。

Unity のビルド環境をクラウドサービスでできることは、とてもメリットが大きいのでぜひぜひ Unity Cloud Build に期待したいですね!

iOS などのスマホから、ビルド結果を直接インストールするのも容易です。最高ですね!

WMF 5.0 (PowerShell 5.0) の再リリース予定が発表されました

WMF 5.0 (PowerShell 5.0) は、2015/12/16 にリリースされてから、12/23 に PSModulePath 上書きをはじめとするバグがあったことで回収されてました。

長らく再リリース日が未確定でしたが、本日リリース予定日として 2016年2月末日が予告されました。

blogs.msdn.microsoft.com

Updated 02/08/2016 – Thank you for your continued patience. We have fixed the offending PSModulePath issue and tested it thoroughly. We are working towards getting properly signed WMF 5.0 RTM builds. Now, we expect that around end of February you will be able to download the revised packages.

ということで、お待ちください。

PowerShell 5.0 で使える機能をまとめた記事も用意してあるので、リリースされ次第公開します。