tech.guitarrapc.cóm

Technical updates

Serverless Conf Tokyo 2018 に来ている記事1 : AWS Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

今年も場所が変わって、東京タワースタジオなのですが、例年よりこじんまりしています。 周りにお店が少しはあるので、今までよりいいかも? (会場は古めですがこういうのでいい)

冒頭の吉田さんの挨拶のあと、AWSセッションで。これもAWSセッションのみ。

引用は私のコメントです。

目次

Speaker

Keisuke Nishitani

@Keisuke69

Serverless の価値

ビジネスを生み出すこと。 このビジネスの創出により集中するために、開発者が必要としているのは、より効率的、俊敏、スケーラビリティの高いサービス。

Undifferentiated Heavy Lifting

付加価値にならない、重い作業は小さくしたい。ビジネスロジックに集中したい。

Undifferentiated Heavy Lifting が大きいと価値が低い。(ランタイムや環境のセットアップ、プロダクションシステムのキャパシティの見積、モニタリング、スケーラビリティ確保、冗長化、認証認可、スロットリング)

Lambda がデてきた2014年

AWS の価値に、Working Backward (お客様の課題に向き合い)というのがあり、課題に対して検討して開発されたのがAWS Lambda。

  • Function
  • Event Driven
  • Never Pay for Idle
  • No Servers to manage

157機能が4年間でリリースされている。(非公開の改善はもっとある)

38% : すでに使っている (+7%) 37% : 今使っていない (-4%) 26% : 今後1年で使う

利用者のうち、69% がLamnda を使っている。

Customer Serverless

Quator ベースだと、ここ1-2年で利用が大きくなっている。 はじめは、Web/Game などのアーリーアダプターが使っていたが、エンタープライズも使い始めている印象がある。

実際、ここ1-2年で事例の発表がエンタープライズからが多い感じ?

サーバーレスの効果

いわゆる Undifferentiated Heavy Lifting なことから解放されますよ。

  • サーバー管理が不要
    • とはいえ、warmup だるいんだが....

  • スケーリング
    • Consumption にするべきだよねー

  • 組み込まれた高可用性
    • ここはS3 障害などが無い限り、可用性はかなり高いのでよさある。

  • アイドル時のリソース確保不要
    • Azure の Service Plan や Always On の違和感はこれ...

    • 0円スタートが可能、かつシームレスに秒間x0000 req までスケールする

Try and Error がしやすいのは良い環境ではある。

サーバーレスの流れ

基本構成はイベント起点。

Event Source -> Funcrion > Service 

OS のネイティブ機能もFunction で利用できて、各種言語が利用できるので、Lamnbda のための特殊な事情を考える必要はない。

TCP通信なら何でもok、UDP はだめよ。

Event Driven Service Event Sources Lambda Inside
AWS La,nda S3 IoT
Amazon API Gateway DynamoDB ....
AWS Step Functions Kinesis Stream
AWS X-Ray SNS

Dev Tools としての Cloud9 や Amplify、SAM、SAM CLIでのローカルテスト、Code Star、CodeCommit、CodeBuild、Code Deploy などの開発ツールも多く用意されている。

これに加えて、各種コミュニティのフレームワークがある。

Serverless とかあるけど、言語依存が厳しい.... Cloud Formation 嫌いだしやだなぁというのがおおい、このあたりはAzure Functions のほうが妥当感ある。Zipデプロイはかなりいいよね。

Use Case

アダストリア

WebAPI -> 新API Interface -> 旧API Interface -> API Server

Web API のこの流れは結構いいですね。開発上かなり柔軟になるし仕組みもシンプル。

Kinesis -> Lambda -> DynamoDB

ログやIoT でよく使われるやつ。

Web -> Stream -> Lambda -> DynamiDB/RDS/StepFunctions

こんなパターン

Lambda -> Lamnda (分類) -> S3 -> Lamnda -> RedShift
                           |                    
                         Athena

Firehorse 使っておけ感もあるけどね、

Firehorse -> S3 -> Lamnda -> RedShift
             |                    
           Athena

ライフサイクルマネージメント

  • Console : Cloud9がLambda のコンソールに埋め込まれているので、手動で書くのもあり
  • IDE : Eclipse/Visual Studio への統合
  • Cloud9 (Cloud IDE) 上でテスト、デプロイまでできるので、まぁ便利
  • コーティングを自分のエディタで + SAM CLI -> AWS Serverless Application Model

SAM CLI : ローカル環境にコンテナデプロいされてテストできるので、ローカルテストに便利。

基本的には、手動はCI/CDが厳しい。 そこで、他のツールでパイプラインを組むのがいい。

まぁ実際ね、そしてこのパイプラインがめんどくさいはめんどくさい。

パイプライン

よくあるAWSの流れでいくと、Code Pipeline でCode Commit -> Code Build -> AWS SAMあたりが繋がれる。

現場、AWSはテストサービスは(Device Farm以外)ないので、3rd party 使うしか無い。

Source Build Beta Test Prodiction
GitHub / CodeCommit Code Build Cloud Formation (AWS SAM) 3rd Party Cloud Formation (AWS SAM)

XAMLを書くときに使っている拡張機能

UWP アプリを書く必要があり、何度か挫折したXAMLに真剣に取り組んでいます。

今回は、XAMLを書くにあたって自分が導入している拡張機能とめちゃめちゃ便利なアプリの紹介です。

目次

拡張機能

次の2つをいれることで、XAML に悩まされることが減ったのでお勧めです。 ときにStylerは、いわゆる自動的なフォーマッターでオススメです。 私がこういう拡張をいれる時に共通しているのは、「機械的に自動化されるのに慣れるのは大事」ということで、フォーマッターはその中で優先して導入すると効果があると感じます。

marketplace.visualstudio.com

marketplace.visualstudio.com

XamlStyler

XAML を書いていて面倒だと感じるのが、コントロールの要素が読みにくいことです。 その原因は、自分にとっては「コントロールごとにプロパティの要素が違ったり、並び順が異なる」ことにあります。 しかし、膨大な数のプロパティとコントロールは自分の好みにあうように並び替えたり管理しきれません、やりたくないです。 管理できないものは「保存時に自動フォーマットをかけて、それに慣れる」と考え事が減るので、自動フォーマットする拡張機能としてXamlStylerを導入しました。

この拡張は@nuits_jpさんに教えていただきました、ありがとうございます!

Visual Studioの拡張機能で導入でき、ソースもGitHub で公開されています。*1

github.com

拡張をいれると、XAMLを開いて保存(Ctrl + s) するだけで自動的にフォーマットしてくれます。 例えば今までいれてなかったXAMLで適用すると、こんな感じでフォーマットされました。

VS拡張の弱点は各自のVS環境に依存することですが、XamlStylerは外部Configurationで設定できます。 Settings.XamlStyler としてプロジェクトに配置しておきましょう。 これでVSの設定よりも優先されるので、チームで統一するにはちょうどいい感じです。

次のコミットで、明示的に制御するために追加しました。

github.com

Script Integrationとしてコンソールアプリもあるので、適当にCIでフォーマットかけることもできます。が、まぁいったんいいでしょう。.NET 4.5.2 だし、Linux/macOS で動かないし。

github.com

Inline Color Picker

XAML上で色設定時にインラインでカラーピッカーを出してくれるColor Picker拡張です。

UIが古いのですが、VS CodeなどでCSS書いていてよくあるアレなのであって便利です。

XAML 記述の確認

ドキュメント優先、よりも動かして目で見てXAMLを確認する方が圧倒的に理解も手も動かしやすいです。

そこで、次の3つのUWPアプリを片隅に表示させて開発しています。

普段からXAML Controls Galleryを開いています。 通常のコントロールの利用方法に悩むことが格段に減ったおすすめアプリです。

このアプリは@okazuki さんに教えていただきました!ありがとうございます。

Windows UI Library が2018年8月に発表され、そのnugetライブラリMicrosoft.UI.Xaml を使ったXAML実装サンプルアプリです。 XAMLで表現できるFluent Design 向けのコントロールのサンプル実装が目的らしいので、ちょうどほしかったやつという感じです。

Getting Started が公開されています。

github.com docs.microsoft.com

アプリはMicrosoft Store でインストールできます。

www.microsoft.com

また、アプリのサンプル実装のソースコードも公開されています。(Microsoft.UI.Xaml使用は、devブランチ参照)

github.com

アプリは標準コントロールの利用例ですが、ソースコードと一緒にみれるのでかなり助かります。

WindowsCompositionSamples

Windows.UI.Xaml を使った最新のデモとコードの確認ができます。

ソースコードも公開されています。

github.com

こちらも Microsoft Storeでインストールできます。

www.microsoft.com

WindowsCommunityToolkit

コミュニティによる、UWPアプリ作成時に使う拡張です。 標準にない便利なコントロールや拡張が多くあります。

ソースコードも公開されています。

github.com

また、MicrosoftからGetting Started が公開されています。

docs.microsoft.com

アプリはMicrosoft SToreでインストールできます。

www.microsoft.com

微妙に使いにくい感じがするので、もうちょっと触ってみないとばっちりかどうかはわからないです。

まとめ

自分にとってXAMLで一番困る挫折ポイントがコントロールや記述がしっくりこないことだったので、拡張やアプリを使ってまじめに取り込んでいます。 さすがにUnityやXcodeやった後だと以前より苦しみが少ないのですが、XAMLは改めてみても独特というかViewをいかに分離できるかを念頭に組まれている感じが強いです。

そのための仕組みとしてのコードビハインド、正確には双方向バインディングが機能としてあるのはかなり強力ですが、XAML独自の記述がネックに感じます。*2 VMでReactivePropertyを使うと、 MVRPと似たコードの雰囲気になります。 結果、違いとなるXAMLとのバインディングを把握すればいつもと変わらないコードの書き味になるように感じるので、この路線でいくのが性に合ってそうです。

そういえば、ReactiveProperty にこのPRが取り込まれると Asyncとの相性が抜群によくなるのではよ.... (困ってたらPR作っていただきました、神か

github.com

XAMLは4Kで多きめのモニタで書いていると効率明らかにいいので、なるほどUnityと同じ....という感じです。

*1:ドキュメントもGitHub参照で

*2:仕組みを理解するのが近道なのはどのフレームワークでも同様ですね

IFTTT と Zapier と Integromat それぞれでGoogle Formsの回答をSlackに通知してみる

「Google Forms に入力があったらSlack *1に通知したい」

今回の記事は、IFTTTやZapier、あるいはIntegromatを使って通知を行う方法についてです。

目次

動機

Google Forms を外部に公開したり、内部に公開して回答を受けてアクションすることは、度々あります。 そして、そのたびに「気づけないと意味がない、でも気付くためにSlackに通知するにはどうすれば楽にできるのか」を悩み勝ちです。

これまでも、Google App Script(GAS)を書いて通知、GASからServerlessにWebhookを投げて通知などをやっていましたが、いずれもコードが必要なためノンプログラマーがカジュアルにやるには苦しいです。 そして、コードでやる以上GitHubで管理したいですが、GASのデプロイとか考えたくありません。 コードを書かない、コードで書く必要がないという選択が必要なシーンも多いので、考えてみましょう。*2

seleck.cc

誰であっても障壁を感じることなく*3、自分の仕事を自動化で楽にして、時間が作れずにできなった本当にやりたいことに注力できる土壌や文化はあってしかるべきだと思っています。

ということで選択するのがいわゆるGlueサービス、と呼ばれるインターネット上の各種サービスをノンプログラミング/レスプログラミングでつなぎ合わせるサービスである、IFTTTやZapier、Integromatです。

普段はどれを使っているのか

私自身は、個人のSlackではIFTTTをメインに構築して、会社としてはZapierを使っていました。

用途 メイン サブ
個人 IFTTT -
会社 Zapier -

これは、次の理由からです。

  • 個人 : シンプルな操作が多く、IFTTTの方が設定の手間が少ない。また、使っているPhilips HueなどがIFTTTにしかない
  • 法人 : SNSからの連携、ChatworkなどIFTTTではできず、複数のZapをかませたいなどZapierではないとできないサービスや処理がある

また、個人としても法人としても「同系統サービスはなるべく1つのサービスで済むなら集約させたい」という思いもあり絞っていました。

Integromatの利用

Integromatは去年から見ていたのですが、いまいち使いたいサービスがなく、すでにIFTTT、Zapierで組んでいたのでスルーしていました。 ZapierやIFTTTに感じていた2つのストレス、「視認性の悪さ」、「ちょっとしたことですぐに処理を挟む必要性」、「Zapierの課金の高さ」を解消できそうなので、Integromatも用いてみました。

用途 メイン サブ
個人 Integromat -
会社 Integromat -

ただし、3日使ってみて Basic($9課金)もした結果、メインをIntegromatにすることはやめてIFTTT/Zapierと併用しています。

用途 メイン サブ
個人 IFTTT Integromat
会社 Zapier Integromat

https://www.integromat.com/en/pricingwww.integromat.com

利用サービスが増えましたが、IFTTT/Zapierでできなかったことを任せられるので、用途を定めればいいかと判断しました。*4

Integromatの強さ

Integromatは、かなり理想的なサービスと思っています。 特に次のポイントを評価しています。

  • ifがなどのフィルタ時でもシナリオのUIが分かりやすい*5
  • 組み込みのパーサーや配列ハンドリングがある
  • 実行分だけとすると無料で1000op/monthという破格さ
  • 課金もBasic $9~とZapierより安い
  • Google SpreatSheetへの書き戻しなど処理が強力

非エンジニアから、シナリオUIが可愛い、理解しやすいと高評価だったことも好ましいと思っています。Zapierは繋ぐとカオスなのですごくいいですね。

↓は2つのmoduleをつなぐUIですが、可愛さです。

Integromatをメインにしない理由

Integromatをメインからサブに戻した理由は、「実際に処理の必要な更新がなく、実行しない場合でもオペレーションが消費される」という特性を使って気付いたからです。 ZapierやIFTTTは、対象サービスの対象処理が実行された時にだけ「Zapなどのオペレーションを消費」するのに対して、Integromatは「スケジュール実行でポーリングする場合、実行されていなくてもスカシ実行でもオペレーションを消費」します。 計算すると、Integromatは通常の15分に一度のスケジュールでも96op/day 消費します。*6 15分スケジュールだと、無料アカウント(1000op/month)でひと月持たず、Basic(10000op/month)でも3ジョブ程度でしょう。「InstantやWebhookがない」けど「高頻度スケジュールで実行したい処理」はIntegromatにあまり向いていないと判断しました。*7

実際に使い始めてオペレーションを消費している原因を把握して、構成を組みなおすまでのOperation消費は次の通りです。

4シナリオで15分頻度スケジュールを実行した結果、一日で388使っているのが分かります。*8

例えば、Google Formsの新規入力があったらSlackやメールに通知、返信、などの処理はなるべくリアルタイムに処理したく15分に一度に設定するとあっという間にいっぱいになります。

IntegromatとZapier/IFTTTの利用用途

Integromatは実行分だけOperationを消費することが確定する処理にのみ利用することにして、次の用途と定めました。

  • Webhook を受けて実行する処理
  • Schedule に Instantがある処理
  • 1op/week、1op/month、1op/yearなど非常に低頻度に繰り返す処理
  • Router/Aggregatorなどを用いて分岐する処理

IFTTT/Zapierは、Integromatで処理が向いていない他の用途に使っています。

  • 対象サービスの特定のオペレーションを起点に実行される処理
  • HueやSNSなどIntegromatで処理しにくい処理

自動化を組むときは、まずIntegromatでInstantに処理できるか/Webhookかを確認、出来なければIFTTT/Zapierという順に利用しています。

Google Forms の回答をSlackに通知してみる

余談が長くなりました。

当初はIntegromatのみの記事を書くつもりでしたが、結局先述の理由でIFTTT/Zapierで組んでいます。

Google Forms は次の構成です。

回答先のスプレッドシートを設定しておきます。

結論どれで組むといいのか

ZapierかIFTTTがおすすめです。

この記事の用途でIntegromatは向いていません。理由は先述の通りです。

ただし、Webhook経由でトリガーが発動して、SpreadSheetに書き込み、Slackに通知、Twitterにポストを行って.... など、InstantなTriggerを起点に処理が実行されるならIntegromatが最高です。

Integromat

シナリオは、Google Forms -> Slackをつなぎます。

まずは、Google Forms モジュールを選択します。

Google Forms Moduleは、SpreadSheetの更新を検知させることができます。

フォームと回答のスプレッドシートにアクセスできるGoogleアカウントで接続し、ファイルとワークシートを選択します。

行は全てでいいでしょう。Formsからの自動生成なら先頭行はカラム名のはずです。

次はSlack通知をつなげます。Add another module でSlackをつなげましょう。

Create a messageでメッセージを送れます。Create a Postだとリンク先に飛べなかったのでMessageでいいかと思います。

あとはメッセージを送るChannelとメッセージを組みます。どのような値が来るかは、直前のGoogle Forms ModuleからのFetchによって可視化されています。

メッセージを作るときには、Text、Math、Date、配列操作、Parseなど強力な関数が用意されているのでZapierのような関数を組む必要がほぼありません。

一度保存します。

試しに今の回答でSlackに飛ばします。Run Onceしてみましょう。

それぞれのModuleに処理数が表示されます。

今回はスプレッドシートに回答がすでに4行あり、Google Forms Moduleの設定時に一度に2行処理するように設定していました。 そのため、Google Forms は1度の処理ですが、Slack Moduleは2度処理されて2つの回答がポストされています。

こういった詳細もわかるのは神ですね。

Slackを確認すると2つメッセージが送られていることが分かります。

あとは確認頻度スケジュール設定です。Integromatは、Zapier/IFTTTと違ってScheduleにInstantがない限りは定期的に実行します。(そしてOperationを消費します)

回答があるたびに実行をなるべく早く送信したいなら、Scheduleを短くすることになりますが、Operationが激しくなるのでものを選ぶのがここです。

Activate にすれば有効になります。

以上で、Integromatの設定は完了です。

ちなみに、Slack送信時にShow Advanced Settings でBotのアイコンや名前などいろいろ調整できます。

Zapier

Zapierの場合は次のように組めます。

Trigger Apps に Google Forms を選択します。

New Responseを選択。

接続するGoogle アカウントを認証してTestします。

トリガー対象のスプレッドシートとワークシートを選びます。

これで完了なので、Fetchして接続を試します。

トリガーを受けたら処理するActionは「Slackへメッセージ送信」です。Slackを選びましょう。

Channel Messageを送ります。

Slackとの接続をテストします。

Slackのメッセージを作ります。Integromat とは選べる内容が異なりますね、行やURLは取れません。*9 送信先のURLはZapierにテキスト埋めなの何とかならないでしょうか。

さぁ、ではテスト実行してみましょう。

Slackに送れていますね。

名前を付けてZapをOnにすれば完了です。

Zapierは、処理が縦に並ぶため複数のStepを組んだ時にどんな流れになるのかが見にくいのかが良くなるといいですね。

IFTTT

IFTTTの場合は、Google Formsではなくスプレッドシートで作成します。

新しい入力検知なので、New row added to the spreadsheetです。

パスかURLでシートを選択します。

あとはthatを選んで、Slackにポストします。

文章を適当に作りましょう。

始めからある程度いい感じの文が入っています。

カラムはプレビューできません。

保存しましょう。

Check now で実行をテストできます。

適当にRowを追加してから実行するとSlackにメッセージが連動します。

これで完了です。

まとめ

Google App Script でコード書いて、という処理に比べるとコーディングがない上にUXがある程度定型化しているのとストレートフォワードなのが分かります。

「誰でもこのような自動化が組め、何かを自動化できそうと気づいたら5分もかからずサクッと組める。」

この良さは、プログラミングをする理由と同様だと思います。 例えプログラミングができなくても、普段「何かをtriggerに手作業で行っていた単純な作業」は自動化できます、誰かにお願いせずとも自分で組める環境は非常に重要です。

もしも簡単に条件付けできるなら、それもZapierやIntegromatで自動化フローに載せられます。*10

例えば、Integromatなら質問1が「オプション 1」の場合はXXXX処理、違うならZZZZもFilterとRouterで簡単です。

ぜひ、普段の提携作業を自動化してしまって、本当にやりたいことをやってください。この記事がそのきっかけになれば幸いです。

*1:Teams でも Chatworkでも置き換えてください

*2:もちろん増えてくると定義をTerraformで~とかInfrastructure as Codeの辿る道がくるのですが

*3:あるいは障壁を意識することなく

*4:Integromatに統一したかったです

*5:英語であることは問題ではない

*6:4op/1hour * 24hour = 96op/day

*7:これらはIFTTT/Zapierで十二分にこなせていることもあり

*8:他にも1op/dayのシナリオをいくつか組んでます

*9:このためZapierでSpreadsheetの再帰書き換えは面倒です

*10:Integraomatの方が簡単に組めます

はてなブログの予約投稿でTwitter投稿をするとFacebookにも投稿されるようにIFTTTを設定する

予約投稿時のFacebookに同時にシェアする機能が廃止されるようです。

staff.hatenablog.com

やりたいことはようは、予約投稿に合わせて自動的にFacebookにも投げられればいいので、IFTTTを使って自動化してみましょう。

前提として、Twitterには投稿しているものとします。

目次

前提

IFTTTのtriggerとしてTwitter検索機能を使うため、以下の条件で発動させます。

  • Twitter投稿は行っている
  • Twitterは鍵垢ではない
  • IFTTTアカウントでFacebook連携しても構わない
  • Facebook投稿はTwitterよりも時間差が生じてもいい(最大15分)
  • #はてなブログ#fb タグを予約投稿時につける

もしも鍵垢の場合、IFTTTで連携しても構わないなら同様の操作が可能です。

通常の投稿時のシェアとの競合回避

#はてなブログタグだけだと、通常の投稿時のシェアタグにデフォルトで含まれて、Facebook投稿をやってしまったときに二重になります。

そこで、IFTTT発動条件のタグとして #fb というタグを追加しました。

公開時のフロー

  1. 記事を書く
  2. 編集オプション > 予約投稿を設定する
    1. Twitterに投稿だけ有効にする
    2. #はてなブログfb タグを有効にする
  3. 記事を予約投稿する

連動結果

Twitter投稿すると、FBにも投稿されます。

なお、#fb タグなしのトリガーに反応させた投稿だとこのようになります。

IFTTTの設定

IFTTTでは以下の設定を行います。

  • Twitter Triggerを選択
  • New tweet from search を選択

  • 検索条件を入力

「Retweetを除外、指定したタグ、アカウント、URLを含む最新のTweet」だけ引っかかります。

#はてなブログ #fb -RT -@アカウント名 はてなブログのURL

  • Facebook投稿は、{{FirstLinkUrl}} のみ

これで完成です。

例えば私ならこうなります。

まとめ

予約ではなく、通常の投稿時のシェアはこれからも使えます。 そして私は一切予約投稿使ってないので、初めてその制約を知りました。

技術的に面白いので、ServerlessやLogicAppを試すのもいいですが、私はこういうのはIFTTT程度で済ませるのが実用的だと思っています。

Fastly Japanが新オフィスに引っ越したと聞いて行ってきた

静的コンテンツだけでなく動的コンテンツもキャッシュしたい、よりユーザーに近いエッジでコンピューティングしたい。そのような時にFastly社の名前が上がってくることが増えてきたと感じます。

先日、Fastly JapanのMio MatsudaさんからFastly日本オフィスを移転したとのことで訪問する機会をいただいたので訪問レポートです。以前サンフランシスコのFastly本社を訪問したのは2016年だったので、2年ぶりの国を変えての訪問になります。

tech.guitarrapc.com

目次

近年のFastly様紹介

Fastly Yamagoya Meetup 2017や、日経新聞さんのCDNをエッジルーティングに使う事例などで話題になったCDNのFastlyさんは、私自身好んで使っているサービスです。

毎年開催されているミートアップ ALTITUDEの内容も興味深いものが多いです。

www.fastly.com

VCLを基盤にしたエッジでのモジュールやディクショナリを行えるSDKの提供に始まり、Realtime everything というコンセプトはCDN側でのロギングや統計をはじめとして「リアルタイムに処理をしたいという要望」に応えてくれます。Fastlyを使っていくには動的な処理をいかにやるか、ということと向き合うことであり、VCLと仲良くやっていくといい感じになります。

www.fastly.com

先日Limited PreviewとしてWAFを出されたことで、IncapsulaでWAF + CDNを、という面もそろそろFastly で対応できそうです。

Web アプリケーションファイアウォール (WAF)(2020) | Fastly ヘルプガイド

Remote Log Streamingに関しても、まだ公式プラグインはないもののDatadog の Log Management との接続ができ、S3やGCS、BigQueryよりもお手軽かつ監視環境に一体化されて良いです。

qiita.com

cloudplatform-jp.googleblog.com

個人的には、GraphQLをはじめとして「API結果をエッジにキャッシュがありな設計」ならFastlyを使うのもありだと感じています。

https://blog.apollographql.com/caching-graphql-results-in-your-cdn-54299832b8e2

また、Datadog のFastly Plugin も機能リクエストした結果、Service Account名をAPIキーごとにつけてチャートに出せるようになるなど、細かなフィードバックにも対応していただけて良かったです。

docs.datadoghq.com

Fastly Yamagoya Meetup 2017でのFastlyの舞台裏のお話しは非常にエキサイティングだったので、ますます注目です。今回の訪問は、これまでサテライトオフィスで頑張ってこられた日本オフィスがどうなるのかを含めて非常に楽しみにしていました。

所在地

新オフィスは新橋駅から徒歩6分程度の場所にある、Tsao Hibiyaとのことでランチ時間に合わせて伺いました。

当日は晴れで、新橋の大通りからすぐなので迷子ガチ勢の私でも迷わず到着できました。

Fastly Japanが入っているビルは2017竣工と新しく外観も中もきれいです。暑かった外から入った時に、緑が爽やかに感じたのが印象的です。

8F に向かいます。

オフィスの雰囲気

エレベータを降りてすぐ左にFatlyならではのセリフ、右にガラス扉があります。

受付はなく、すぐに働かれている皆様が見えたのでご挨拶をしてフロアにお邪魔しました。

[まさかの写真を忘れました!!]

広々としたフロアにはまだデスクも少なく、サンフランシスコ同様扉がないオープンスペースで開放感があります。当日は9名の方がおいでで、席の半分は空席でした。伺ったところ、暑くなってきてリモート勤務されている方が増えてきたとのことで、働く場所が自由なのが日本でも徹底されており素敵です。

固定席の隣には、USから来られた方のためのフリーアドレススペースが広々とあります。

デスクスペースの脇には、ゆったりとしたソファスペースがあり、Fastlyクッションやブランドカラーと同じ色の調度品がさりげなくあります。

壁にはFastlyといえばといったフレーズがあり、反対側にはメンバーの方の写真があるのもサンフランシスコと同じ雰囲気を作っていました。

会議室は「速いもの」をテーマにサンフランシスコで命名されており、日本ならではと言える「新幹線の名前」が採用されていました。

なるほどHAYATE。

会議室は、会議室状況が入口のタブレットで把握できること以外にもZoomが完備されています。

特に圧巻だったのがSAKURAです。Zoomで会議が始まると、天井にあるカメラを自動的にホワイトボートに向けたり、自在に共有する視点を調整できるようになっています。ナニコレスゴイ。Fastly社のファシリティ担当者がサンフランシスコから来て設定されたそうです。エキサイティングですね、やりたい!

キッチンスペース

オフィススペースの隣にはキッチンスペースがあります。ここまで見てきた通り、サンフランシスコと同様のファシリティの提供を基本に設計されており、同じレベルの社内サービスを提供するというファシリティ担当者の熱い情熱を感じます。毎週定期的にランチが振る舞われるのも同様で、日本ではUber Eatsや出前館を使って皆さんで集まって食事をとられているとのことです。

サンフランシスコにもあったのと同じトースターがあるのにはコダワリを感じました。*1

ドリンクスペースもあり、ゆっくり過ごしてほしいという感じが伝わります。*2

キッチン横のオープンスペースの壁はブランドカラーとなっており、ここでもブランドイメージが徹底されています。

世界時計があるのもサンフランシスコと同じで、世界をまたにPOPがあるという印象が強いですね。

しばしお話しを伺った後、お土産にFastly Tシャツもらっちゃいました。(通算4枚目)

さいごに

いかがでしたでしょうか?引っ越しに際しては、突然水曜にパッキングしてとアナウンスがあり金曜に移転したという話もあり、相変わらずのスピード感がおもしろ素晴らしかったです。

これまでのサテライトオフィスは会議室の確保に難儀されていたとのことで、新オフィスは会議室が豊富にあり楽しい雰囲気でした。サンフランシスコと同じ雰囲気を随所に感じるので、Fastly様でミートアップなどの機会が将来行われることを楽しみにしています

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

*1:こういうコダワリ好きです

*2:IPAもあるのが印象的です