YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

SRE NEXT 2020で登壇してきました #srenext

はじめに

こんにちは、Stackdriver担当者です。先週の土曜日に豊洲フロントで開催されたSRE NEXT 2020に登壇者として参加してきました。

sre-next.dev

どのセッションもすでにSREプラクティスを実践して試されているお話を聞けて、DevOpsの実践方法としてのSRE(Site Reliability Engineering)の広がりを感じられる素晴らしいカンファレンスだったと思います。

自分のセッションについて

sre-next.dev

自分のセッションは「サイト信頼性エンジニアリングの原則」というタイトルでの発表でした。資料は諸事情で一般公開できないのですが、主旨は概ね「SRE サイトリライアビリティエンジニアリング」(通称: SRE本)の書かれていることの抜粋とサマリーだったので、すでに実践されている方にとっては振り返りのような内容になってしまったかと思います。セッションスライド自体の公開を避けているのは、話した内容を伴わずにスライドに書かれている文言だけを切り取られると解釈によってはネガティブにも捉えられないなと思っていることによります。よって、このエントリーでお伝えしたかったことを再度簡単に触れていこうと思います。

なおSREに関するトピックをすべて触れていくとSRE本でもカバーしきれていないほどなので、これがすべてだとは決して思わないでいただきたいです。

単純性と一貫性

信頼性の担保とシステムの改善の両立のためには、変更はすばやく導入し、障害はすばやく戻すことが欠かせませんが、そのために単純性と一貫性が重要な役割を果たすという紹介をしました。

複雑性には必要な複雑性と不必要な複雑性が存在しますが、たとえば複雑性の例としてはpolyglotなマイクロサービスが挙げられるでしょう。プロジェクトにおけるプログラミング言語の選択というのは単にアプリケーションロジックだけではなく、それを実行するランタイムやそれをアプリケーションとしてバンドルするためのビルドシステム、依存するライブラリの更新など、実際にシステムにデプロイするまでに多くのツールやプロセスを必要とします。(以下エコシステムと呼ぶ)また採用やトレーニングといった人的なプロセスにも関わってきます。

プログラミング言語1つにつきそうしたエコシステムが伴うため、扱うプログラミング言語の数が増え扱うものが増えれば、管理にかかる負荷も増大します。プログラミング言語、設定管理方法や扱うOSの標準化を行うことで、SREが管理する技術範囲が限定され、かわりにより深い改善が行えるようになることでしょう。

どこまでを標準とするかは、導入する複雑さが得られるメリットほどの価値があるものかを検討する必要があると思います。すべてのユースケースではベストにならなかったとしても、1つを選ぶことで全体として管理が楽になることは間違いないでしょう。

モニタリングとアラート

モニタリングに関しては、1つの対象に対して異なる方法でのテストをおこなえるのであれば行ったほうが正確な状況を把握しやすい、という話をしました。よくある例はホワイトボックスモニタリングとブラックボックスモニタリングで、前者はシステムの内部情報の点検、後者は外形監視などが挙げられます。

モニタリングを行う理由はシステムの状態の把握と、障害の事前や事後のアクションを行うための通知(ページング、呼び出し)の設定などですが、ページングの設定を行う際の思いやりのなさにより、結果呼び出される側が疲弊することがあります。たとえば次のような場合はページングではなく、より緩い対応で済むはずです。

  • 冗長構成でクラスタ or マシンが1台だけ落ちた
  • 非常に長時間をかけてディスク使用量が95%になった
  • 仮想マシンが基盤クラスターが原因で落ちた
  • 対応しようのない障害

上で「より緩い対応」と触れましたが、たとえばアラート機構にはページングも含めて次のようなものが挙げられます。

  • ページ(呼び出し): オンコール対応
  • チケット/バグ/ダッシュボード: 当直対応、割り込み
  • ログ: 原因調査
  • メール: 後述するが極力使わない

オンコール対応というのは「担当者が寝ていても叩き起こして対応してもらう」ようなレベルのものを指します。SREで重要なのは一部の数字ではなく、ユーザー体験にどれくらい悪影響を与えているかなので、たとえば上記の冗長構成でマシンが1つ落ちたような場合は、引き続きサービスがリクエストを捌けているなら、業務時間中に落ちたマシンの復旧とそ原因を究明すれば良い話なので、この場合はチケットに登録しておけば良いでしょう。

どのレベルでの対応にするか判断のためにも外部プローブ(外部からのDNSクエリやヘッドレスブラウザなどを使ってTTFBの計測など)などのデータをあわせて計測するのが良いでしょう。

で、アラート機構としてメールを推奨しない理由ですが、運用方法によっては解決できる点もありますが、次のような理由が挙げられます。

  • 対応の様子を追跡できない
  • 障害に対するオーナーが不明
  • SN比
  • 人間の警戒に依存

cronや様々なシステムで簡単に設定できるのでメール通知を設定しがちですが、メールは傍観者効果が発生しやすかったり、なまじ簡単に設定できるためにノイズが多すぎて無視されやすくなったりします。inboxが他の業務メールと共通なことも多々あるため、注意深くフィルターしたり携帯の通知の設定も適切に行われなければいけません。こうしたものを運用で改善するよりは、適切なツールを用いたほうが効率が良いでしょう。

モニタリングとアラートに関しては当日 @larufa1 さんがVoyage Groupでの体験を共有してくださっていました。

speakerdeck.com

自動化

SREはトイルをできる限りエンジニアリングで排除するという姿勢で行うものなので自動化は常につきまといます。

たとえば複数のホストに手動でSSHを行って設定しているような処理があれば

pssh -H HOST1 -H HOST2 -H HOST3 "
  apt-get upgrade &&
  /usr/local/bin/make-new-widget.sh &&
  [ -f /etc/widget.cfg ] && echo Success || echo FAIL "

という形で自動化の第一歩が進められます。さらに推し進めていくと例えばGCPなどでは

gcloud compute instances create foo1 \
    --metadata-from-file startup-script=mysite/install-puppet.sh

このような形でスクリプト内に必要な処理を埋め込むことで抽象化のレイヤーを上げていけます。プログラムを書くときと同様に抽象化のレイヤーが上がることでより多くの処理をプログラムに任せられます。

ステートフル vs ステートレス

ステートフルなサービスは名前のとおり「状態」を持つサービスのことですが、「状態」を非常に簡単に定義すると「再生成が難しい一意なデータ」と言えると思います。障害が起きた場合はその「再生成が難しい一意なデータ」を復旧させなければならなくなり、それに備えて専用のバックアップ/リストア機構、また専用のモニタリング機構、アーキテクチャが必要となります。

たとえばMySQLクラスターにおいて

  • マスター(読み書き可): 1台
  • レプリカ(読み込み専用): 複数台

という構成があった場合、マスターノードには専用のモニタリング機構やバックアップ機構が必要になるでしょう。これらははじめのほうで触れた複雑性の議論にも関わってきますが、ステートフルなサービスがシステム内に増えれば増えるほどこうした機構が増えるので、なるべくステートレスなものに置き換えていけるような設計が肝心です。

情報の信頼先

あるシステムの特定の情報を得るために複数の情報ソースがあることは珍しくありません。その場合何を正とするかで判断が変わってきます。時計が1つなら何時か即答できますが、時計が2つだとどちらか正しい時刻か判断できません。

なのでたとえばシステムの状態を把握したいときはなるべく1つの情報源に頼るようにし、それが本当に判断するための情報源として適切か、設計時に判断したいところです。たとえばプロダクションサーバーと退役したサーバーが同居している系から返されるトラフィックのHTTP 2xx系の割合を調べたいときは、一番上流のSLBの層で得られた情報で判断するのが正しいでしょう。

SLOとエラーバジェット

SREで真っ先に出てくるのがSLOとエラーバジェットの概念です。

SLOで可用性99.5%を設定し、それを達成した場合に、これは「100%を0.5%達成できなかった」とみなすのではなく、文字通り「99.5%の可用性を達成した」と同時に「0.5%分システム改善のための余裕がある」という状態であるとみなすことが肝心です。

この0.5%を使ってたとえば

を試せます。可用性の話で言えば、0.5%であれば1ヶ月間に3.6時間が確保できます。たとえばカナリアリリースを実施している場合、これまでそれが起因のダウンタイムがなかったのであれば、すべての変更を canary → stable を経てローンチするのではなく、変更内容の大小やフラグの重要度に応じてカナリアの期間を短くする、あるいはカナリアをスキップするといった選択も取れるかもれません。

3.6時間は与えられた猶予なので、現実としてSLOよりも高い可用性を実現できてしまったとしても、無為にSLOを厳しくしてしまうのではなく、エラーバジェットをより迅速あるいはより堅牢な仕組みの導入のために利用するのが健全でしょう。

逆に厳しいSLOを設定してしまうと、アジリティが確保できなくなる可能性が高くなります。また当然ながらコストも高くなります。(一般的に 9 が一つ増えるごとに倍以上のコストがかかると言われている。)逆に言えばSLO 100%は「動かしたが最後二度と止められない」ということですから、通常のサービス運用ではまず必要のない値です。ユーザーに与える影響を加味しながら、なるべく余裕が得られる値に設定にできるよう、設定値に関して継続的な振り返りが必要です。

補足ですが、SLOの設定やその運用に関しては @chaspy さんが当日話されていました。

speakerdeck.com

テストとロールバック

SREを行う上で「システムは必ず落ちるものだ」という考え方を持つことは多くの場面で姿勢を正しくしてくれます。その一環でたとえばテストやロールバックを正しく行うことでシステム障害からの復旧を迅速に行ったり、障害範囲を限定できます。

  • 漸進的なロールアウト
  • 変更導入後の検証
  • 準備済みのロールバック

たとえばカナリアリリースは漸進的なロールアウトの例で、一部のクラスタ、各クラスタの1台だけ、など、限られた場所にだけ変更を導入して影響範囲を限定してリアルなデータで検証を行えます。問題があれば事前定義されたrunbookを実行してロールバックします。エラーバジェットは有効に使わないといけないので、SLOに影響を与えそうなエラーを発見したらすぐにロールバックして、原因究明のためにエラーバジェットを消費しないようにします。

障害耐性

エラーバジェットの消費として一番もったいないのは障害の復旧作業にそれを充てることです。したがって極力障害が起きないような対策を 打つことでより有意義にエラーバジェットを利用できるようになり(=システムの前向きな改善に使え)ます。

たとえばあるサービスをプッシュしたら空の設定ファイルを作ってしまってしまって、それが原因でサービスの再起動後にサービスが落ちてしまったという障害があった場合に、どうやって障害耐性をつけたらよいでしょうか。

いくつかの改善策が考えられますが、たとえば

  • Gracefulな退役: 新しい設定が読み込めない場合は以前の設定を使い続ける
  • 差分による予防: 設定の差分が単純に20%以上ある場合、あるいは特定のフィールドに変更があった場合には特定の検証プロセスを通るまでプロダクションにプッシュしない

などが挙げられます。

ポストモーテム

SREのおいてポストモーテムは最も重要と言える文化かもしれません。先程も書いたとおり「システムは必ず落ちるもの」と想定し、問題があった場合には人間ではなく「プロセスと技術」に注目して、「プロセスと技術」で改善を行うために振り返りを行います。決して人間を非難しないことが重要です。

たとえば次のようなポストモーテムがあったとします。

  • 事象: グローバルDNS障害
  • 原因: エンジニアが named.conf をtypoして保存してした。それをグローバルにプッシュしてBINDを再起動した。
  • アクションアイテム: エンジニアが次からはもっと注意する。エンジニアはリスクが高い変更を金曜日には行わない。

ここで問題なのは、原因をエンジニアとしていることと、アクションアイテムを人間に依存していることです。また「もっと」のような具体性を伴わない表現がされていることも問題です。原因はtypoをしたエンジニアでなく、typoがある設定ファイルがテストもなしにグローバルに展開されてしまうような仕組みです。またアクションアイテムも、それをどうプロセスやエンジニアリングで解決するかが書いてありません。これは次のように書き直せるでしょう。

  • 事象: グローバルDNS障害
  • 原因: 不正な named.conf がテストなしにすべてのBINDホストにプッシュされた。
  • アクションアイテム
    • 予防(こうした障害の再発をポジティブに防ぐにはどうしたらいいか)
      • named.conf をデータベースから読み込む
      • プッシュと再起動をスクリプト化して、スクリプトに安全確認を組み込む
    • 検出(同様の障害を正確に検出するまでの時間を減らすにはどうすべきか)
      • 監視の頻度を改善する
      • 監視対象の変更
      • ページをより速く行う
    • 緩和(次回この種の障害が起きたときの深刻度や影響度の%を減らすにはどうしたらいいか)
      • リロードして、再起動しない
      • 1つのサーバー(カナリア)だけ他のサーバーよりも速くプッシュするようにスクリプトを変える
      • DNSの機能を分割する(例: 内部 vs 外部、権威 vs 再帰
    • 修正(次回障害が検出されたときにどうすればより速く回復できるか)
      • オンコールプレイブックに起こすべきアクションを追加する
      • すばやくロールバックできるように各ホストの直前の設定を保存しておく

おわりに

こうした内容をお話しましたが、すべてを一度に導入しなければいけないというわけではなく、また何かを行うことでSREという認定が受けられるとかそういうたぐいのものでないので、システムの信頼性を高めるためにこうしたベストプラクティスを少しずつ導入していくのが良いのではないかなと思いました。しかし、とはいえ1つ、これがなければSREではないというものを挙げるとすれば、それはシステムのユーザーに対して信頼性を維持し高めることに貢献しているかどうか、ではないでしょうか。当たり前ですが、そうでなければ Site Reliability Engineering とは呼べないと思います。

SREのプラクティスであるSLOの設定というのはそういう意味では非常に妥当だと考えています。営利企業がITシステムを活用したサービスを提供している場合、会社の成功には必ずユーザーの満足度というのが存在し、経営の中では収益に紐付いた指標(KPI)とその目標値を設定しています。その会社の収益を支えるものがITシステムなのであれば、それらのKPIはSLIと紐づきますし、KPIの目標値はSLOと紐づくはずです。

今回SRE NEXTでは多くの企業がすでにSLOベースの運用をされていて、それらの事例を知ることができ大変有意義だったと感じています。ぜひ次回が開催されることを願うとともに、今後ますますSREのプラクティスが普及し、発展していくことを願っています。

参照

landing.google.com

このサイトに原文ではありますが、”Site Reliability Engineering” と "The Site Reliability Workbook" が無償で公開されていますので、気になる方はぜひ読んでみてください。特に両者ともに気になるトピックだけ拾い読みするだけでも問題ないと思います。

また書籍以外にもSLOのワークショップなどのコンテンツがありますので、こちらもぜひ見てみてください。

なおご存知の通り、"Site Reliability Engineering" は日本語訳版が出ていますし、また "The Site Reliability Workbook" に関しても現在日本語訳版が発刊に向けて最終段階だと聞いております。

YAMAGUCHI::weblogの2019年を振り返る

はじめに

こんにちは、Stackdriver担当者です。今年も振り返りがやってきました。今年はあまり多くのことができなかったのですが、振り返りのために書いておきます。

あと例のやつを貼りました。よろしくお願いします。

関連エントリ

ymotongpooの2019年

去年立てた目標

  • ログに関する知見の向上
    • オブザーバビリティ領域でも特に来年はログの領域の知見を高めていきたいと思っています。
  • ジム
    • 2年半以上続けているので来年も頑張ります。来年は絞りたい。
  • 部屋の片付け
    • いろいろとものが増えてきたので不必要なものは捨てつつ、デッドスペースの有効活用などをしたいと思います。

オブザーバビリティ領域に関して

クラウド関連

Google CloudのDeveloper Relationsチームでオブザーバビリティ領域の担当としてStackdriverだけでなく自社が関わっているオープンソースプロダクトであるOpenCensusOpenTelemetryなどの知見を広めつつ、より多くの開発者に利用してもらいフィードバックを集めるべく、イベントの開催やイベントでの登壇、カスタマー企業でのインタビューなどをしていました。

など

とくに今年はOpenCensusとOpenTracingが6月のKubeCon EUでOpenTelemetryにマージすることが発表されたので、Stackdriverへの対応やOpenTelemetryコアメンバーとの定期的なディスカッションなどをして初期リリースのタイミングでの仕事をしていました。

特に今年の11月にあったVelocity BerlinでのOpenTelemetryの3時間ワークショップはいままでになかった経験で、異なる会社の複数のメンバー、しかも住んでいる国や都市もバラバラなチームでオンラインでワークショップのコンテンツを作りつつ、本番一発勝負でワークショップをこなしました。

その時の知見の一つがこちらのエントリで書いたものです。

OpenTelemetryはようやくMetrics部分の仕様が落ち着きつつある段階なので、来年はいよいよ各種APMツールなどの対応が進み、実用例も増えてくるのかなと思います。OpenCensus meetupはOpenTelemetryへのマージが発表されてからは開催せずにもろもろ落ち着くまで様子見していたのですが、来年は新しく用意されたconnpassグループでイベントをまた再開していきたいなと思います。

opentelemetry.connpass.com

また3月に書いたこのエントリーで「オブザーバビリティのオンラインコミュニティをやりたい」というコメントを書いて、実際discordのサーバーを立ち上げたのですが、やっぱりオンラインのコミュニティはなかなか難しいですね。

来年はまずはこじんまりとオブザーバビリティ周りを様々な角度からワイワイとやるオフラインな会をちょこちょこやっていきたいなと思います。

Go関連

今年も @tenntenn さん、@budougumi0617 さん、@micchiebear さん、@shibu_jp さんといったみなさんとGo Conference の運営を行いました。

特にGo Conference 2019 Autumnは今後に向けて「有償化」「平日開催」という試みをしたわけですが、多くの方に参加いただき、これまでのGoConと変わらぬトーククオリティで、次に繋がる会になったなあと思いました。

また福岡ではfukuoka.goの方々を中心として初めて東京以外の都市でGo Conferenceが開催され、運営の品質の高さに驚くとともに、日本のGoコミュニティのさらなる拡大も感じました。

今年から新設されたGo GDE (Google Developer Expert)に日本から @tenntenn さんと @mattn さんが初期メンバーとして選出され、日本のGoコミュニティの世界とのつながりが強くなっていくのも実感しました。来年もDeveloper Relationsチームとしてお二人の活躍をサポートできればと思っています。

個人的にはGo関連ではプロファイラーやパフォーマンスチューニング周りの知見を深めた一年でした。

Stackdriver Profilerの開発チームが google/pprof の開発も担当していることもあり、来年は pprof を中心としたGoプログラムでのパフォーマンスチューニングなどを広く共有できればなと思います。

生活

去年の終盤からいろいろと状況が変わって、自分の時間というのがだいぶ減って、平日夜や週末の時間の使い方というのがだいぶ限られた感じになっています。そういうなかでイベントへの参加というものを改めて考えると、もっと違ったあり方があってもいいなと以前より強く思うようになりました。

そしてそれと同時に多くの人に支えられていることを実感した1年間でもありました。自分が時間的に制約があってできない分、人に積極的に頼って、結果としてより大きなことができたような気がします。

@tenntenn さんとオンラインコミュニティの強化の話などを最近はしているので、上のオブザーバビリティのチャットコミュニティなどでもうまく進めていけるようにしたいなと思います。

出張/旅行

今年も出張や旅行で国内外を移動しました。

  • 2月: Sunnyvale
  • 4月: Hawaii
  • 5月: Cleveland, Mountain View
  • 6月: Singapore
  • 7月: 福岡、San Diego
  • 8月: 京都、Chicago
  • 9月: 大阪
  • 11月: Berlin, San Diego
  • 12月: Bangalore, Hyderabad, Chennai, Delhi, 山梨

特に今年は初めて行く国が年の最後に立て続けにあったのと、その2つの出張がそれぞれ自分にとって新しい挑戦だったのもあって刺激的なものとなりました。都市自体に感じたことは別のエントリーに書きました。

すでに来年の3月のカンファレンスのプロポーザルが通ったり、来年頭にはチームのオフサイトイベントがあったりと出張の予定がいろいろと決まっているので、来年も体調を崩さないように頑張りたいと思います。

ジム

上のような調子だったので、3-4月、9-10月あたりは最大週5回ジムに行くなど充実したジム生活を送っていたわけですが、11月から12月頭にかけては、週2回が限度でした。

時差がある都市に行くと時差ボケで体調が万全でなくなるだけでなく、出張中は様々なイベントを1日に詰めているため、朝起きたあとすぐか、アルコールを摂取しないでホテルに戻ったあとにしかジムに行けないため、なかなか行く時間を作れないのがもどかしいです。またジムに行けたとしても、ホテルのジムは設備がまちまちで、ダンベルセットがあっても最大で20kgだったり、そもそもフリーウェイトの設備がなかったりと、満足の行くトレーニングはなかなかできません。

また上述した生活の変化により疲れがたまったからか、今年はついに初めてぎっくり腰になりました。

ぎっくり腰になってすぐに海外出張にいくことになった - YAMAGUCHI::weblog

30代後半にもなるとやはり体のどこかに支障が出てくるわけで、鍛えるというよりもこういうことを予防するための側面をより強めていこうと思う一年でした。

FP業

去年FP 2級の資格を取ってからほそぼそとFP業をやったりしていて、月で均すと飲み会代の足しになる程度の副収入があったりした1年でしたが、コンスタントに相談をもらえているのはありがたいなと思いました。

また自分でFP業をやるだけでなく、もっと色んな人に知見を共有したいなと思って次のようなイベントを開催したところ、多くの方に関心を持ってもらえました。

connpass.com

第2回を行う予定でいたのですが、予定がいっぱいで気がついたら年末になってしまっていたので、来年また開催出来ればなと思います。

またFPに相談はしたいけれど、いきなり行くと商品を売りつけられそう、という印象を持っている人も多くいることを知りました。独立系のFPはそういう心配を取り除いて、真に必要な知識を共有しつつ顧客のプランを立てるのが仕事なので、そういうものに興味がある方がいたらご連絡ください。

来年に向けて

  • オブザーバビリティ関連の展開
    • 今年よりも露出を増やしつつ、OpenTelemetryやpprof周りの開発に積極参加
  • 執筆/翻訳をまとめる
    • 複数の書籍関連の話があったにもかかわらず進捗が大変芳しくなく、各所にご迷惑をかけたいので、来年中に終わらせます。
  • FP業の展開
    • 独立系FPとしてより展開していきたいです

2019年に買ってよかったもの

はじめに

こんにちは、Stackdriver担当者です。今年も残すところあと僅かとなってまいりましたがみなさんいかがお過ごしでしょうか。

2019年に買ってよかったもの

Anker PowerPort Atom PD 2

自分は良く出張、特に海外出張に行くことが多いんですが、そのときに無駄に重くて不便だなと思っているのがMacBook Proの電源アダプターです。あれだけ重いのにもかかわらずUSB-Cの口が1つしかないというはあまりに苦痛。そこでサードパーティー製の製品を求めたわけですが、電源アダプタなので粗悪なものだと発熱や発火が怖いため、信頼のAnkerで買いました。

Power Deliveryが2口あって最大60Wまで出力できるので、MacBook Proを充電しつつ携帯やiPadなども充電でき、カンファレンス会場などでもとても便利に使えています。正規品よりもサイズがひと回り小さくて軽くなっているのも助かります。

ホテルではPCにつなぎつつ、後述するモバイルバッテリーの充電も可能なので、このアダプター1つで出張のほぼすべての電源が必要な用途がまかなえています。

Anker PowerCore 10000 PD Redux

Ankerが連続登場です。これまでは出力用ポートがUSB-Aで電流2.1Aがだせる10000mAhのモバイルバッテリーをつかっていましたが、これがなにぶん大きくて重かったのです。すでに自分が出張で持ち運びする電子機器がMacBook ProiPad Pro 11''、Pixel 3 XLとすべてUSB-Cなので、ケーブルもすべて両端USB-Cのものに変えたいという気持ちもあったのでモバイルバッテリーを買い替えました。

で、このモバイルバッテリーを買ったわけですが、同じ10000mAhでもサイズが小さい上に重量も200gを切っているので軽くて最高です。PDなので携帯を充電する際にも短時間で済みますし、これ自身を充電する際にもPDなのでホテルにもどってから寝るまでの間に充電が完了するなどメリットばかりです。

タブレットアーム

昨年末にiPad Pro 11''を購入するまで家で使っていたiPad miniは出張に持ち運ぶだけでなく、就寝前にベッドでYouTubeを見たりWikipediaを読んだりするのにも常用していたのですが、iPad Pro 11''の購入によって就寝前だけに主に利用されるようになりました。 で、その用途で使う場合にいままで手持ちでiPad miniを抱えていたのですが、何分手が疲れる。ということで、このタブレットアームを購入し、ベッドのヘッドボードに固定したところ、YouTubeの視聴が信じられないほど快適になりました。Netflixを見ながら寝落ちすることもしばしばあります。

小型財布

財布に関しては地元山梨への愛着もあり、長年印傳屋の財布を愛用していて、特に近年はキャッシュレスな生活を送っていたので、印傳屋のカードケースと小銭入れをメインに使っていました。

印傳屋のものはそれぞれに物としては良いもので、かつ価格もお手頃なので、いまでもおすすめできるのですが、自分の用途の場合どうしても「カードケース+札入れ」の機能を持ったものが欲しくなり、上のカードケースだとカードスリーブの中に札を折って入れるというような、ちょっと残念な運用になっていました。 またしばらく使っているとカードスリーブの端が切れたりして、ちょっと残念な感じになってきました。とはいえ、マネークリップを持つのはちょっとはばかられたので、カードケースとしての機能がメインで、紙幣をうまく収納できるものがないかと思いしばらく探していました。そうしてセクション冒頭のSEDRIDのミニ財布を見つけたのです。

SECRIDのカード入れの部分には最大6枚のクレジットカードが収納でき、収納ケース下部のフックを動かすと中のカードがきれいに段差をつけて押し出され、かんたんにカードを取り出せます。カードをしまうときはただ押し込むだけです。ボタンを外すと更に2枚分のカード収納ポケットがあり、免許証や保険証などを入れておけます。また中に紙幣を挟むためのクリップがあり、普段使う分くらいの紙幣は問題なく収納できます。


SECRID Wallet Review | Miniwallet Crisple Black 'RFID Wallet'

紹介動画や写真ではボタンを外した内側のポケットに小銭を入れて、これ1つで「カードケース+札入れ+小銭入れ」のすべてをこなすという紹介もありますが、小銭まで入れると型崩れが起きるので自分は小銭は先の印傳屋の小銭入れに入れています。ちょうど2つとも同じ大きさなので持ち運びもコンパクトです。

f:id:ymotongpoo:20191217081144j:plain

REMOWA Essential Sleeve 37L

11月にベルリン出張に行ったときに奮発して買いました。日本で買うと市場価格では並行輸入品を入れても9万円前後するものが、ドイツでは国産ということもあり、また免税も手伝って6万5000円くらいで買えます。

いままでは機内持ち込みスーツケースは社会人1年目のときに買ったナイロン製のものを使っていて、それもいい仕事をしていたのですが、いい加減古びてきたのでリモワを初めて買いました。アルミのものも良かったのですが、とりあえず軽くしたかったのでポリカーボネート製のものに。またドイツ出張があったら考えます。

これで2020年の出張も乗り切れそうです。

Goのハンズオン環境としてGlitchを使う

はじめに

こんにちは、Stackdriver担当者です。この記事はGo Advent Calendar 2019の24日目の記事です。昨日は@fist0さんでした。

私は職業柄「コードラボ」「ハンズオン」「ワークショップ」と呼ばれるような、参加者に実際に手を動かして課題を解いてもらうことで特定の技術や製品を理解してもらうイベントを開催したり講師をしたりすることがあります。その場合にこちらがコントロールしづらいものの一つが実行環境です。諸々のバージョンを固定したり、コンテナを用意したり、などいろいろな方法がありますが、今回はglitchを使ってGoでのハンズオン環境を用意する方法とその使い方を紹介します。

TL;DR

Glitchを使ってGo用のハンズオン環境を容易に提供できる。サンプルプロジェクトはこれ。

glitch.com

Glitchとは

glitch.com

ウェブアプリケーションを公開する無料の実行環境で、デフォルトではNode.jsの実行環境が用意されています。日本語でGlitchの丁寧な解説をしている記事もありますので詳細はそちらに譲ります。

で、今回はこのGlitchをGoの実行環境として利用する方法について紹介して、さらにハンズオンなどで便利に使う方法についても解説します。

準備するもの

主催者・チューター

  1. Glitchアカウント
  2. Goのハンズオン用にセットアップされたGlitchプロジェクト
  3. (optional) 2.のコードをミラーするGitHubレポジトリ

参加者

  1. (optional) Glitchアカウント

手順

1. Glitchアカウント

フェデレーテッドログインができるので好きなIdPを選んでアカウントを作ってください。すぐにできます。参加者はアカウントが無くても一時アカウントが利用できるので大丈夫です。

2. GlitchプロジェクトをGo用にセットアップする

メインはここです。GlitchはデフォルトではNode.jsの実行環境なのですが、実はGoの実行環境も実は入っています。しかし、設定ファイルを書くことで、Goのダウンロードとインストールをして特定のバージョンのGoを使わせたり、コード変更時のGoプロジェクトの自動ビルドなどを設定して、さらにハンズオン環境として良い物にできます。

glitch.json

Goを含むNode.js以外のランタイムは glitch.json と呼ばれる設定ファイルを用意する必要があります。JSONで設定できるフィールドはそれぞれ次のとおりです。

{
  "install": string,
  "start": string,
  "watch": {
    ...
  }
}

それぞれ次のような内容です。

  • install: プロジェクトのコンテナ起動時に実行されるコマンド
  • start: watchで定期的に実行されるコマンド
  • watch: watch.json に関する設定(watch.json を別途作成する場合は書かなくて良い)

watch.json

watch.json というファイルを設定すると、編集後に自動で実行したいコマンド等を記述できます。Linux等のwatchコマンドに似ていますね。ここではどのファイルを変更した場合にどういったトリガーを起動するかを設定します。対象ファイル名は正規表現で指定できます。

{
  "install": {
    "include": [
      "^glitch\\.json$",
      "^init\\.sh$",
      "^\\.env$"
    ]
  },
  "restart": {
    "exclude": [
      "^go/",
      "^pkg/"
    ],
    "include": [
      "\\.go$"
    ]
  },
  "throttle": 5000
}

設定項目はそれぞれ次のとおりです。

  • install: include で記載されているファイルが変更されるとコンテナ自体の再インストールが行われる
  • restart: exclude で記載されているファイルが変更された場合は何もしない、include で記載されているファイルが変更された場合はコンテナを再起動する
  • throttle: watchの確認自体の間隔を設定する(ミリ秒)

Go用プロジェクトセットアップのコツ

これは通常のコンテナイメージ構築の場合と勘所は同じです。つまり次のようにします。

  1. Goのバージョンを固定する
  2. go.mod でパッケージのバージョンを固定する

1のGoのバージョンの固定は、glitch.jsoninstall に適当な初期化用のシェルスクリプトを指定して、その中でLinux用のtarballとsha256のチェックサムの確認をすることで固定できます。上のサンプルプロジェクトではこのような形で設定しています。

GO_ARCHIVE=go1.13.5.linux-amd64.tar.gz

if [ ! -d /tmp/go ]; then
  cd /tmp
  if [ ! -f /tmp/${GO_ARCHIVE} ]; then
    wget -q https://dl.google.com/go/${GO_ARCHIVE}
  fi
  sha256sum -c ~/${GO_ARCHIVE}.SHA256SUMS || (echo "failed to verify go tarball" && rm /tmp/{$GO_ARCHIVE} && exit 1)
  tar -xzf ${GO_ARCHIVE}
  rm /tmp/${GO_ARCHIVE}
fi

mkdir -p /tmp/pkg
if [ ! -L pkg ]; then
  ln -s /tmp/pkg $GOPATH/pkg
fi

そしてこのSHA256SUMSのファイルは自分で手元で作成してもいいですし、Go公式サイトの配布先に書いてあるSHA256 Checksumを自分でコピーして作成しても良いでしょう。

512103d7ad296467814a6e3f635631bd35574cab3369a97a323c9a585ccaa569  go1.13.5.linux-amd64.tar.gz

2.の go.mod は固定です。ハンズオン参加者に編集させていはいけませんし、go mod tidy を実行させてはいけません。アンタッチャブルです。編集させると即座にプロジェクトが予想しない形に壊れるので、もし触ってしまった人がいたら元のgo.modファイルとgo.sumファイルを再度コピーしてもらうようにしましょう。またキャッシュも消す必要があります。

そしてプログラムのビルドと実行も glitch.jsonstart で指定したシェルスクリプト内で go fmtgo run 等を実行するようにし、ハンズオン参加者が go コマンドを自分で打つ必要がないように設定すると良いでしょう。

(optional) 3. 2.のコードをミラーするGitHubレポジトリ

万が一ブラウザではなくローカルで実行したい、もしくは何らかの事情でGlitchを使えない、という人がいた場合に備えて、GlitchのプロジェクトをGitHubミラーリングしておくと安心感が高まります。

注意点としては、事前にExport先のレポジトリを作成し、かつ1つでもコミットがされた状態にしておく必要があります。その上で "Export to GitHub" ボタンを実行してExport先のレポジトリを指定すると、giltchブランチに変更がpushされます。

f:id:ymotongpoo:20191219112030p:plain

実際にミラーしたのがこちらです。

github.com

ハンズオンの進め方

ハンズオンの進め方はまずハンズオン開始時に上の 2. で作成したプロジェクトのURLを参加者に共有します。参加者に "View Source" を押してもらい、コードエディターが読み込み専用モードで開いてもらいます。ここで画面の右上の "Remix to Edit" のボタンを押してもらうと "Remix" が行われます。

f:id:ymotongpoo:20191219141140p:plain

参加者がRemixをすると元のコードをforkしたプロジェクトが任意のIDとともに作成され、参加者は自由に変更を加えられる環境を手に入れられます。そして課題を書き進めるわけです。わからないことがあったら、その部分のコードをハイライトします。すると手を上げたアイコンが出現するのでそれを押すと、質問が出来るようになります。

f:id:ymotongpoo:20191219140615p:plain

remixしたプロジェクトで質問がでると、remix元のプロジェクトオーナー(つまりチューター)のトップ画面に「質問が来ていますよ」というメッセージが出てきます。("Help Others, Get Thanks→" の部分。ここでは "Test question: bra bra bra" という質問メッセージが来ています。)

f:id:ymotongpoo:20191219140344p:plain

もちろん普通に手を上げてもらっても良いのですが、こういう形で質問をしてもらうことで、チューターがスクリーンなどにこのトップ画面を映していると質問内容がわかりつつ、これからその部分に取り組む人も事前に注意が出来るというわけです。

実際に試した

この方法は今年の11月5日に行われたVelocity Berlin 2019のワークショップで実際に試してみました。チューターや参加者のパソコンのOSがWindowsLinuxmacOSChrome OSなど様々に分かれていたわけですが、OS特有のエラーなどにはまることがまったくありませんでした。

参加者が書いた結果のコードもプロジェクトの形で残るので、何か面白いことを取り組んだ参加者がいれば、そのプロジェクトURLを共有してもらうだけで手元でコードを見て、実行するところまでできるのも便利でした。

またハンズオンの内容もHTTPサーバーを立ててリクエストを受け取ったり投げたりするようなプログラムを書いたわけですが、ポート番号3000番で指定すればパブリックにサーバーを公開できるので、参加者同士で通信しあうような課題もできそうだったのが魅力的でした。

f:id:ymotongpoo:20191219142722p:plain
実際にGoでHTTPサーバーを立ててHello worldをしている様子

コンソールにアクセスしてコマンドを実行できるため、CLIを作るような課題もある程度可能です。

f:id:ymotongpoo:20191219142925p:plain

おわりに

コードラボやハンズオンは実際に手を動かすため短い時間で効率よく学習することが可能です。ぜひこの方法をいろいろな場所で試してもらって、Goのハンズオンとしてもっと便利な使い方を共有してもらえたらなと思います。

明日は最終日。担当は @tenntenn さんです。

インドに行ってきた(出張編)

はじめに

こんにちは、OpenTelemetry推進委員会です。この記事はpyspaアドベントカレンダー20日目の記事です。昨日は狂人Emacs使いのmopemopeさんが担当でした。

先のインドに行ってきた(準備編)に続き、今度は実際に現地に行って感じたことなどを記録として残しておこうと思います。インドに行ってきたとはいえ、多くの方が期待するようなバックパック旅行でのサバイバル記や現地の人々の交流記といった類のものではなく、出張でホテル滞在を繰り返して、体調の維持を最優先として、現地での4回の登壇をそつなくこなすための行動を取った結果のものなので、仕事で行く人にしか参考にならないと思われます。

旅程

もう一度旅程を振り返ります。

都市 日程
クアラルンプール 12/1-2
バンガロール 12/2-4
ハイデラバード 12/4-6
チェンナイ 12/6-7
デリー 12/7-9

今回は経由便を使ってバンガロールからインドに入り、3回の国内移動を経たあと、最後デリーから直行便で日本に帰るという旅程でした。よくよく考えると1週間で4箇所の移動は日本国内の出張でも結構大変なので、単純に移動だけでも体調を崩さないように特に気をつけていました。

気づき

様々な気づきがあったのですが、それらを順不同で乱雑に書き並べてみました。

イベント参加者の熱気やリクエストがすごい

まずイベント登壇者としてインドに行かないとわからないことを先に書いておこうと思います。インドの4都市で登壇したわけですが、どこの会場でも登壇後の質問攻めやLinkedInでのフレンド申請がものすごくて、その熱気に圧倒されました。

インドではTwitterよりもLinkedInのほうが人気のようで「LinkedInには1ヶ月に1、2回程度しかログインしないよ」と伝えても、「それでもいいからつながろう」と言われ、ときには「今申請を出したから今確認をしてほしい、今ここで承認してほしい」と確認を取るまで逃してくれない人もいました。

街を歩いて思ったことでもあるのですが、これだけ人口が多く、また格差も激しい社会、しかもカースト制度は表向きには禁止されているとはいえまだ文化には根深く残っている話を聞くと、ITの世界で勝ち上がっていくという意思を感じるのも納得しました

野良犬や野良牛が多いが野良猫がいない

バンガロール空港(ケンペゴウタ国際空港)に降り立ち、初めてインドの地に立ってまず最初に感じたのは「野良犬が多い」ということ。まず空港の外に出て、迎えのタクシーの乗り場に行くまでの3分の間に3匹の野良犬を見かけ「なるほど、これは狂犬病がなくならないわけだ」と勝手に納得しました。*1

f:id:ymotongpoo:20191204084935j:plain

実際、WHOの報告によると2017年時点でインドでの狂犬病による死者数はアジアの60%弱、全世界での35%を占めるようです。

Rabies is a major burden in Asia, with an estimated 35 172 human deaths per year. India accounts for 59.9% of rabies deaths in Asia and 35% of deaths globally.

また報告によるとインドには1500万匹の野良犬がいるそうで、狂犬病の対策のためにもそういった野良犬をどうしていくのか、動物愛護の観点からも様々な議論がされているようです。

そしてインドといえば牛。「ヒンドゥー教では牛を神聖視しているので街中で牛を見ても誰も手を出さない」というのはよく聞く話です。実際に街中では牛をたくさん見かけました。次の写真は車道を逆走している牛。

f:id:ymotongpoo:20191217162901j:plain

しかし、ヒンドゥー教で元々神聖視されている牛は「コブウシ」という種類の牛で、自分が想像していたようなホルスタイン等々の乳牛は特にそういった神聖視の対象ではなかったようです。実際に水牛なんかは普通に運搬用途で使われていました。

f:id:ymotongpoo:20191202155226j:plain

単純に無用な殺生をしないという理由で街中を自由に闊歩している牛というのはかなり多そうだなと思いました。

そして不思議に感じたのは野良猫の数です。これだけ野良犬や野良牛は見かけたのに、インドの自分が訪れた都市では野良猫をまったく見かけませんでした。英語日本語問わずネットで調べた限りだと

  • インドで猫を愛でる習慣がまだあまりないため猫が生きづらい環境
  • 野良犬が多すぎて食べられたり競争に負ける
  • ヒンドゥー教でネズミは神の遣いとされているため、そのネズミを食べる猫は憎むべき存在となっている

など様々な説を見かけたのですが、なかなかに自分が腹落ちして納得できる説は見つかりませんでした。

自由すぎる交通事情

バンガロール空港に降り立って、そこから車で市内に向かうまでに受けた洗礼はインドの自由すぎる交通事情でした。これまで欧米諸国ぐらいにしか行ったことがなかった自分にとって、インドの交通事情はカルチャーショックでした。車線を守るとか横断歩道を渡るとかいったことが文化として当たり前な国ばかりしか行ったことがなかったのだと思い知らされました。

バンガロールの街中を歩いていたときに撮影した動画を見てください。


Traffic in Bangalore

これはまだ混雑がない道路を撮影した動画ですが、車が車線関係なく走っている様子や、4車線ある道路を人が複数人横断している様子などがわかると思います。とにかく車、リキシャ(オート)、バイクがひっきりなしに走っていて、隙間を縫って動かないと前に進めないから仕方なくこうした運転をしている感じでした。

f:id:ymotongpoo:20191206114225j:plain

この写真は一見普通に駐車場かなにかで人が行き来している様子に見えますが、実際は普通に5車線くらいある幹線道路で渋滞しかけている状況で撮影した写真です。道路というのが車だけのものでなく、停めることができると判断したら人は勝手に降車しますし、勝手にタクシーに乗り込みます。

f:id:ymotongpoo:20191203194048j:plain

バイクは混んでいる道でもすり抜けることができるため、かなりポピュラーな移動手段に見えました。ガソリンスタンドでもバイクが大人気です。

f:id:ymotongpoo:20191205202335j:plain

こちらの写真は一家でバイクに乗っている様子です。ヘルメットをかぶらないスタイルで乗っている人がかなり多く見られました。複数人でバイクに乗っているのもかなり当たり前な感じでした。

f:id:ymotongpoo:20191205193458j:plain

ユンボも工事が終わったらそのまま道路を走って帰ります。こんな状況ですから自分の位置を周りに知らせるためにとにかくみんなクラクションを鳴らしまくっています。

大気汚染は本当にすごい

いま書いたように道路にはとにかく大量の車やバイクやリキシャが走っているし、事前情報で大気汚染がすごいという話を聞いていたので、すごいことになってるんだろうなとは思っていましたが、実際に目にすると毎回驚かされます。


Night market near Charminar

この動画はチャーミ・ナールという歴史的建造物のそばの夜市の様子ですが、なんとなく白く霞んでいるように見えるのが解ると思います。これはカメラの性能とかそういう話ではなくて、普通に肉眼でも同様に見えているもので、つまり大気汚染です。バンガロール、ハイデラバードはこの程度でしたが、デリーは飛行機から着陸の様子を眺めていたときにすでに驚くほど霞んでいました。

デリーのイベントはホテルの1階にあるカンファレンスルームで開催されたのですが、参加者の受付時刻になり受付への出入りが多くなると、だんだんと外の空気が廊下に流れ込み、誇張でなく廊下の上の部分が白く霞み始めたので、本当に大気汚染が深刻であることを実感しました。

www.cnn.co.jp

イベントは12月上旬に開催されたのですが、その1ヶ月前にはディワリヒンドゥー教の祝日)があり、通常の大気汚染に加え花火や爆竹が大量に使われたため特に大気汚染がひどくなり、そのせいで飛行機が視界不良で離着陸できなくなる事態にまでなっていました。

実際バンガロール、ハイデラバード、チェンナイでは大気汚染がひどいと感じていても現地の人はマスクなどしていませんでしたが、デリーでは現地の人でもマスクや口に覆いをしている人もちらほら見かけました。次の写真は帰国の日にフマユーン廟に寄った際に見かけた警備員の方です。

f:id:ymotongpoo:20191219082854j:plain

美味しいインド料理もお腹は壊す

今回の出張は8日間で4都市を移動し、各都市で登壇しなければならなかったので、再優先事項は「登壇時に健康な状態でいる」ということでした。したがって食事もストリートフードなどは一切チャレンジせず、極力ホテルもしくは現地オフィスの信頼できる同僚の勧める店のみで食事をしていました。

おかげさまでスケジュール前半はまったく問題がなく、念の為ビオフェルミンは飲んでいたおかげもあるかもしれないけれども、特に違和感を感じることはなく、毎日本場のインド料理を楽しんでいました。

f:id:ymotongpoo:20191204200743j:plain

私は日本にいるときからインド料理が好きだったので、毎日本場のインド料理が食べれるのが嬉しくて、勧められるものはアレもコレも食べていました。写真はハイデラバードビリヤニです。他にもパニプリ、ヴァダ、サンバーなどなど、出てくる料理は美味しく食べていました。

しかし、連日3食インド料理を食べ続けた結果、私の胃腸はついに限界に達し、ある朝トイレに行くと、大きい方の用を足していたはずなのに、出てくるものは液体のみ。下痢を通り越して、液体でした。最初は感染症を疑ったのですが、熱などはいっこうにでないし、お腹も痛くはない。ただお腹の調子が極端に悪くなってしまいました。ピーク時は何を食べてもお腹を下す自信があったので、持っていったポカリスエット粉末をプロテインシェーカーで水で割って、一晩それをひたすら飲み続けていました。

ピーク後はあいかわらずお腹は緩い状態ではあったのですが、結局それ以上ひどいことにはならず、帰国後はすぐに治ったので、連日のインド料理による油とスパイスの刺激で胃腸がやられていたのだと判断しました。

実際インドに旅行に行く人が患う下痢全般を指して "Delhi Belly" という言葉があるくらい一般的なもののようですね。(Wikipediaの記事では感染症として説明していますが、現地ではそれにとどまらず旅行者の患う下痢症状全般をそう呼んでいるようでした)

ムスリムが多かった

インドに行くまでは「インドといえばヒンドゥー教」と思っていましたが、実際に現地に行くと思っていた以上にイスラム教徒が多く、また街にもモスクなどイスラム教に関する施設を多く見かけました。次の動画は時差ボケで朝5時に起きたら外からアザーンが聞こえてきたときの様子です。


Adhan in Bangalore

実際、インドにおいてムスリムは人口の15%程度存在し、2億人弱存在するということを、このことに気がついてインドで調べて初めて知りました。しかしながら、Wikipediaの記事等にもあるとおり、インド国内においては80%近くの大多数が ヒンドゥー教のため、ムスリムに対する迫害も存在します。

自分が帰国してすぐにデリーで「反イスラム」的だと言われる市民権関連法に関するデモが起きていました。e-VISA申請時にも信教に関する質問事項があるので、イスラム教と回答した場合には何かあるのかもしれません。

www.afpbb.com

過去も両宗教の対立が原因でパキスタンの独立が起きているので、複雑な気持ちになります。

www.nna.jp

またインドのイスラム主義組織がテロなどを起こしていることもあり、次のように施設のセキュリティが厳しくなりました

大人数が集まる施設のセキュリティが厳しい

バンガロール空港に初めて着いたときには「空港だし厳しいのだろう」くらいにしか思わなかったのですが、その後各都市に移動したりホテルに行ったり観光施設に行くと、毎回X線による手荷物検査と金属探知機による身体検査を必ず求められました。

ja.wikipedia.org

きっかけはこのムンバイでの同時多発テロのようです。外国人が多く宿泊する施設でも2箇所でテロが起きて多くの死傷者があったので、それ以来出張で訪れる人が宿泊するようなホテルでは必ず手荷物検査をしています。もっともX線検査のモニターの前にいる警備員がスマートフォンを眺めてたりして「本当にこれ機能してる?」と思ったりすることは多々あるのですが。

蚊が非常に大きい

インドに着いて感じたのは外を歩いているときに見かけた蚊のサイズが大きいということです。日本であのサイズの蚊を見かけたのは地元の山で見かけたくらいです。羽音も非常に大きく「ハエが飛んでるのかな?」と思ったくらいです。確かにあれでは通常の虫除け程度では効かなそうでした。

その他

非常に雑多な気づきが多くあったため、これまでに書いたもの以外にも

  • ホテルでは無限にペットボトル入りの水をくれる
  • 道路の舗装状況が良くないためベビーカーを押している人がまったくいない
  • 暑くてもハーフパンツを履いている人を見かけない
  • バンガロールのKRマーケットで行き倒れのおじいさんを見かけたり、ゴミ袋の中で残飯を食べている幼児を見かけて辛くなった
  • スズキ、トヨタヒュンダイ、タタの車が非常に多い

などが気付きとしてありました。

明日は @takabow です。

参照

*1:厚生労働省によるWHOの報告書のまとめによると2004年時点で世界で狂犬病が発生している国のうちインドは狂犬病発生数で1位