無印吉澤

Site Reliability Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。

SRE NEXT 2020 にスタッフ参加しての感想(ロゴデザイン、CFP レビュー、司会などの裏話)

f:id:muziyoshiz:20200127000336p:plain:w640

SRE NEXT ご参加いただきありがとうございました!

sre-next.dev

1月25日(土)に、SRE に関する国内初の大規模テックカンファレンス、SRE NEXT 2020 が開催されました。私も、こちらのイベントにコアスタッフとして参加していました。参加者、登壇者、スポンサーおよびすべてのスタッフの皆様、本当にありがとうございました。お疲れさまでした!

発表内容は全然聞けていない(詳しくは後述)ので、内容についての感想はまだ書けません。しかし、「参加ブログを書くまでが SRE NEXT」と言われてしまったので、取り急ぎスタッフとしての感想を書いてみます。

スタッフ参加の経緯

元々 SRE Lounge のボランティアスタッフだったので、こういうイベントを開催したいというアイディアは北野さんや小熊さんから聞いていて、最初から参加させてもらってました。

本格的に動き出したのって、4月頃の飲み会でしたっけ?(うろ覚え)

この頃に、プロジェクト管理に Backlog を使うことを僕から提案して、SRE NEXT のための Backlog スペースを用意しました。最初に作られた課題(チケット)を見てみたら、作成日は2019年4月14日でした。

スタッフとして担当したこと

先に自分がやってないことから書くと、イベント全体のディレクションや、当日の設備周りなどは、他の優秀なメンバーに任せっきりにしてしまってました。

あとから考えると、僕は勉強会の運営側にまわったことがほとんどなくて、「SRE NEXT をどうしたい」というビジョンが全然無かったなぁと。SRE Lounge みたいな話がたくさん聞けるイベントがあったらいいなあ、くらいでしたね。

そのため、僕はサポート役として「面倒だけどやらないとまずい」系のタスクを色々拾ってました。

  • SRE NEXT の Backlog スペースのアカウント管理
  • ロゴデザインの発注
  • Tシャツデザイン、サイズ確認、発注、配布
  • ステッカー発注
  • CFP のレビュー(複数人でのレビュー会に参加)
  • Room A(メイン会場)の司会

ロゴ、ノベルティデザイン

デザイン関係については、いままで全くやったことがなかったので、四苦八苦しながら進めました。

新しくイベントを始めたい場合、僕と同じように困る人も多いと思うので、ロゴとノベルティに関する情報をまとめておきます。「SRE NEXT みたいにいい感じに作ってよ」 と言われた場合、以下の通りにすればなんとかなります。

ちなみに、以下の情報は全部 Backlog の課題に記録しておいた情報から引っ張ってきました。Backlog は素晴らしいサービスですね! なんと SRE も東京福岡京都で募集中みたいですよ!(SRE NEXT ツールスポンサー関係者による熱いダイレクトマーケティング)

ロゴ

EmbulkFolio のデザインの事例を見て、ここでよさそうということで発注先を 99designs に決定。

色々プランがあって悩んだのですが、ロゴコンペのブロンズプランを利用しました。「非公開コンペ」などのオプションは付けませんでした。

そして説明文を書いて発注。公開コンペなので、具体例はこちらから確認できます。

99designs.jp

優秀なデザインが集まるか不安だったのですが、最終的にはデザイナー15名から応募がありました。説明文は日本語で書いたのですが、デザイナーに日本人はいなかったようで、やり取りは結局すべて英語でした。

その多数のデザインから最終案まで少しずつ絞っていくのが大変で、もらったデザインの画像を Slack に貼り付けて、poll 機能で投票してもらう、という作業を何回も繰り返しました。

99designs 自体にもアンケート機能があるのですが、選択肢が最大8個までという制限があります。99designs では1人のデザイナーが、1個のデザインの複数のバリエーションを投稿してくるので、そのなかから大体の方向性を絞りたい、という段階では全然使えませんでした。最終選考のときだけは使えたかもしれませんけど……。

Tシャツ

Tシャツは、僕の方でロゴを加工して、いくつかデザイン案を作って、Slack の poll 機能で選考。デザイン決定後、僕が以前に使ったことのある FirstBall に発注しました。

デザインのベースは TR180/Trysail5.9oz Tシャツ。色はスタッフ用がサックスブルー、プレゼント用(登壇者、個人スポンサー)がブラック。スタッフ用は「スタッフが見つかりやすいように目立つ色」「SRE 本が青だからやっぱり青系でしょ」というコンセプトでした。

FirstBall では、印刷してから3ヶ月なら版の追加料金がかからないため、「試しに1枚刷る→問題なければ全員分刷る」というステップを取りました。実際、最初の試し刷りでは、実際に着てみるとロゴが大きすぎることに気づいたので、このステップを取ってよかったです……。

f:id:muziyoshiz:20200126232601j:plain
一歩間違えたらスタッフ全員に配布されていたクソデカロゴT

ステッカー

ステッカーって、扱ってくれる会社も多いし、選べるオプションも多くてホントに困りました。そのため、以下の基本方針を決めてから、いくつかのサイトを見て回りました。

  • ノートパソコンに貼ったときに剥がしやすい
  • 光沢のある感じよりは、マットな感じにしたい
  • 発注枚数は1000枚(参加者分だけなら500枚で足りるが、少し余分に作る)

この条件を満たすなかで、一番安かったのはデジタ でした。以下のオプションで発注すると、SRE NEXT ステッカーと同じ感じになります。

  • アート紙
  • 再剥離のり
  • マットラミネート
  • 四角形裁ち落とし
  • 5x5cm
  • 裏スリットなし
  • シートの形は40パス以内無料
  • 7営業日

Sのところでステッカーの外枠もカーブしてるのが素敵。こちら、スタッフの奥さん(デザイナーの方)のアイディアで、パスの調整までしてくれました。

f:id:muziyoshiz:20200126233252j:plain
Sのところでステッカーの外枠もカーブしてるのがチャームポイント

CFP のレビュー

スタッフの仕事の中で一番楽しかったのが、CFP のレビューでした。

SRE NEXT に来場した方はわかると思うのですが、実績があって、プレゼンも面白いエンジニアからの CFP が本当にたくさん届きました!

そういう優秀なエンジニアが書いた CFP の具体例にたくさん触れるのは勉強になりましたし、更にそれを自分と同様に SRE をしているメンバーと「ここがよい」「この点ではこちらがよい」と議論するのは楽しかったです。ここだけで、苦労の元が取れた気がしました。

反省点としては、自分にとっての面白さだけでセッションを投票してしまって、SRE NEXT 全体としてのバランスにはあまり配慮できなかったことでした。そのあたりは他のメンバーに助けられましたが、そういう意識が最初からあれば、もっとうまくできたのでは……と反省したところです。

Room A(メイン会場)の司会

いままで、小さな勉強会の司会くらいしか経験したことなかったので、それと同じくらいの気分で「Room A はメイン会場だから、最初から最後まで面白いセッションが聞けるだろう」と立候補しました。ただ、もう全然そんなことなかったですね。面白くなかった、という意味ではなくて、全然集中できなかった、という意味で……。

今回は参加者が400名を超え、メイン会場のキャパは Room A〜B を繋いで大部屋にした状態で300名。これが小さな勉強会と同じはずもなく、

  • セッション開始時以外にもたくさんある各種アナウンス
  • 音響スタッフとの、オープニング動画を流すタイミングの調整
  • 登壇者への段取りの説明
  • 質疑応答をする・しないのタイムスケジュール管理
  • インカムからの指示による臨時のアナウンス追加

などなどがあり、講演を聞いてる最中もまったく集中できませんでした(気づくのが遅い)。

途中で代わってもらえたら、もうちょっとイベント自体を楽しめたかもですね。前日に急遽決まったオペレーションも多かったので、司会業をうまくマニュアル化できず、複数人で分担できなかったというのが今回の反省点でした。1人で仕事を抱える SRE はダメな SRE……。

聞いていた方はどうだったんでしょうね。耳障りでなければよかったんですけど。とりあえず今日になって #srenext 司会 で検索して、特にネガティブなコメントはなかったので一安心してるところです。

f:id:muziyoshiz:20200126233556j:plain
基調講演に使われたメイン会場(photo by weekendcycler

SRE NEXT プロジェクト全体を通しての感想

大変でしたけど、大規模なテックカンファレンスの裏側を体験することができて面白かったです。また、自分の興味がある技術分野で、同じ分野にいる同業者と知り合いになれて、普段会わない人(特に自分より若い人)の考えを聞く機会がたくさん得られました。

SRE NEXT 2021 が開催されるかはまだわかりませんが、SRE として働いていて(あるいはまだ働いていないけど興味があって)、この分野の技術コミュニティに参加したいという方には、スタッフとして参加することをお勧めしたいと思います。もし SRE Lounge に参加したことがなければ、まずはこちらに参加してみてください。SRE Lounge の Slack ワークスペース に入ってもらえたら、次回の開催情報もそのうち流れると思います。

さて、これからしばらくは全講演のスライドを見て、感想ブログを読み漁る生活だ……。

2019 年に SRE をしながら考えが変わったこと

f:id:muziyoshiz:20191230205919p:plain

今回の記事は年末スペシャルです。

僕が SRE をしながらやってきた取り組みについては、今年も会社のテックブログに色々書かせてもらいました(職場の理解のおかげです。いつも感謝してます)。

ただ、それぞれのブログ記事の間を埋めるストーリーというか、その背景にあることについてはなかなか書く機会がありませんでした。なので、今回はそれらの記事を引っ張りながら、今年 SRE をしながら考えていたことをつらつらと書いていこうと思います。

この1年で考えが大きく変わったこと

SRE のあるべき組織体制について、1年前はこう考えていました。

  • 複数の開発チームをまたぐ形で SRE をマトリックス的に配置して、SRE はアプリの開発状況を細かく把握しながら監視・運用すべき

ただ、この1年で考えが変わり、いまはこう考えています。

  • SRE をマトリックス的に配置するのは、確かに、開発速度を一時的に上げるのには効果的
  • ただ、そんなスキルがある SRE をたくさん集めるのは難しいし、集められたとしてもそんな働き方をさせたらすぐ疲弊して退職しかねない
  • 持続性を優先するなら、アプリの監視・運用の責任は開発チームが持ち、SRE はそれを支えるシステム作りに労力を割くべき

こう書くと、なんか、結局当たり前の結論に帰ってきてしまった感じがしますね……。SRE って元々そういうものだろ、と言われそうな気もします。ただまあ、どういう過程を経てそういう考えに落ち着いたのかを振り返ってみます。

1年前(2018年末)に考えていたこと

去年の年末の時点で、僕個人はこういう状況でした。

  • SRE は複数の開発チームをまたぐ形でマトリックス的に配置されていた
  • 僕個人は、Play 化プロジェクトに関わる開発チームに参加して、監視・運用全般を担当していた

2018年前半から、「SRE をマトリックス的に配置したほうがうまくいくだろう」という議論があり、それまで1つの SRE チームだったものを複数の開発チームにまたがる形にしました。Dev と Ops が分離してしまっていた当時の状況では、それが最適なチーム構成だろう、と僕も強く同意していました。

f:id:muziyoshiz:20191230210236p:plain
SRE Lounge #5 の発表資料からの引用

このあたりの話に興味のある方は、SRE チームの黎明期を知るメンバに繰り返しインタビューして書いた発表資料やブログ記事がありますので、そちらをぜひどうぞ。

muziyoshiz.hatenablog.com

nulab.com

で、この人員配置の中で、僕は2018年4月から今年の7月まで「Play 化プロジェクト」というリプレイスプロジェクトに参加してました。もちろん、SRE 同士の横の連携はありましたが、このプロジェクトの状況を熟知して動いていた SRE は1人だけという状況でした。

backlog.com

開発チームに SRE が入り、インフラとアプリの両方に目配せすることで、いろいろな問題を未然に防げたという手応えはありました。その一方で、このプロジェクトで SRE として1人頑張り続けることのつらさも強く感じていました。2018年末はそんな状況でした。

2019 年に考えていたこととやったこと

そこから1年経って、2019年末(現時点)の状況はこう変わりました。

  • SRE は開発チームから出て SRE チームに所属する。SRE チームは開発チームを支援するかたわら、SRE 主導での改善プロジェクトも進める
  • アプリの監視は、開発チームに徐々に移行しつつある
  • 僕個人は、改善プロジェクトの1つを進めている(※この内容も、いずれテックブログに書きます)

SRE と開発チームの分離は、2019年の年始に、SRE が改善活動を主導できる体制作りを目的に行われました。実は、僕は当初この分離には反対していました。

しかし、リプレイスプロジェクトでの経験を経て、SRE を特定の開発チームに割り当てるのは、短期的には有効だけど、長期的には持続可能じゃないという考えに変わりました。

考えが変わった理由の第一は、開発速度が早い開発チームに SRE として張り付け続けるつらさを実体験したからです。リリースが少ない安定したサービスならともなく、リリースが日々活発に行われるサービスでは、張り付けられた SRE の負荷が大きすぎる。これでは SRE はすぐ疲弊して、退職されてしまうだろうと……。どれくらい大変かの具体的な話は、リプレイスプロジェクトが終わったときのブログ記事に書いたので、よかったらこちらをどうぞ。

backlog.com

考えが変わったもう一つの理由は、SRE Lounge などの勉強会で、いろいろな他社事例に触れたことです。特にメルカリの Microservices Platform Team の事例では、開発チームへの監視・運用の移行がここまで現実に可能なのかと驚かされました。例えば、いろいろな勉強会で触れられている microservices-starter-kit について以下のイベントで初めて知り、懇親会でメルカリのエンジニアに詳しい話を聞いて感銘を受けました。

muziyoshiz.hatenablog.com

それまでは、マイクロサービスは自分の現場に合うのかどうかがずっと疑問でしたが、「SRE とアプリ開発者の責任分界点を明確にするため」という目的さえブレなければ、マイクロサービス化を推し進めていいのではないかと考え始めました。

メルカリの事例に強く影響を受けて、その後、自分の現場でも、アプリ開発者に監視業務を移行するためのアラート通知システムを整備しました。マイクロサービス化まではまだ進んでいませんが、責任分界点を明確にするためには、これからマイクロサービス化を段階的に進めていく必要があると思っています。

f:id:muziyoshiz:20191230210434p:plain:w600
開発チームを巻き込んだ監視システムの全体像(下記ブログから引用)

backlog.com

ちなみに、開発チームに1年以上いたおかげで、アプリ監視の業務設計ができて、結果的にこのアラート通知システムも作れました。その点は、1年以上悪戦苦闘したのも無駄な努力ではなかったのかな、と。

来年1発目のイベントは SRE NEXT

上記でメルカリの事例について軽く触れましたが、SRE の業務について考えるにあたって、他社の事例を聞くのはとても参考になると実感した1年でもありました。

僕は去年から SRE Lounge というコミュニティのスタッフとして参加しているのですが、同じコミュニティ主催の大規模イベント SRE NEXT がとうとう来年1/25(土)に開催されます。いまのところ、僕は Room A の司会としてスタッフ参加している予定です。

すでにチケットは売り切れてしまっています(すみません!)が、発表スライドは後ほどいろいろな登壇者が公開してくれると思います。僕もイベント当日は見てる余裕がなさそうなので、あとから発表スライドやレポートブログなどをゆっくり読ませてもらうつもりです。

来年末も、今とはまたいろいろ考えが変わってるのかなあ。どうなんだろう……。

Amazon Elasticsearch Service の認証・認可に関する面倒くさい仕様をなるべくわかりやすく説明する

f:id:muziyoshiz:20191130143741p:plain

はじめに

最近、仕事で Amazon Elasticsearch Service(以下、Amazon ES)を本格的に使う機会があって、認証周りの仕様で苦労させられました。

Elasticsearch を本格的に使う人は、自分で Elasticsearch クラスタを立てたり、Elastic Cloud を使ったりしてしまうからか、Amazon ES 周りの情報は意外と見つかりませんでした。せっかくなので、今回の記事では、自分が Amazon ES を使うにあたって調べた情報をまとめてみます。

いろいろな Elasticsearch

Amazon ES は、オープンソースの全文検索エンジン Elasticsearch をベースにしたマネージド型サービスです。

Elasticsearch は、Elasticsearch 社*1が主に開発しているオープンソースソフトウェア(OSS)です。しかし、いまはその派生が色々出てきてしまっているので、この記事では以下のように呼び分けます。

提供形態 名称 概要 この記事での呼称
OSS Elasticsearch Elasticsearch 社が主に開発している OSS。X-Pack と呼ばれる拡張機能があり、その大半は有償オプションで利用できる。 OSS 版
マネージドサービス Elasticsearch Service Elasticsearch 社が提供する Elastic Cloud と呼ばれるサービス群の一つ。AWS, GCP, Azure にデプロイされるマネージドサービス。X-Pack の機能を含む。AWS 等に固有の機能はない。 Elastic Cloud
マネージドサービス Amazon Elasticsearch Service AWS が提供する Elasticsearch のマネージドサービス。AWS のサービス群と統合するために、各種拡張が行われている。X-Pack の機能は含まないが、同等の機能が一部実装されている。 Amazon ES
OSS Open Distro for Elasticsearch 「Elasticsearch へのタダ乗り」との批判を受けて、Amazon ES のソースコードの一部を OSS として公開したもの。Amazon ES と同一ではない、と宣言されている。この記事では触れない。 -

なぜこんな話が必要かというと、Amazon ES と、Elasticsearch 社が提供する OSS 版および Elastic Cloud では、大きく違っている機能が多いからです。この記事で解説する認証・認可の方法も、そのような機能の一つです。

Amazon ES の基本

Amazon ES では、「ドメイン」という概念が新たに導入されています。このドメインと Elasticsearch のクラスタは1対1対応です。なので、Elasticsearch をすでに知ってる人は、Amazon ES のドキュメントでドメインという単語が出てきたら、クラスタと読み替えてもらえればとりあえず OK です(参考:よくある質問 - Amazon Elasticsearch Serviceの「Q: Amazon Elasticsearch Service ドメインとは何ですか?」)。

Amazon ES のドメインを作る際には、パブリックネットワークに設置するか、VPC に設置するかを選ぶ必要があります。それぞれ「パブリックアクセス」、「VPC アクセス」と呼ばれます。

  • パブリックアクセス
    • グローバル IP アドレスを持ち、インターネットから直接アクセス可能なドメインを構築
    • 構築後にパブリックアクセスから VPC アクセスに変更することはできない(逆もできない)
  • VPC アクセス
    • グローバル IP アドレスを持たず、VPC に設置されて、インターネットから直接アクセス不可なドメインを構築
    • 構築時に選んだ VPC とは別の VPC に移すことはできない
    • ドメインの作成時にパブリックサブネットを選択しても、エンドポイントにグローバル IP アドレスを設定することはできない

VPC アクセスには、グローバル IP アドレスの有無以外に、機能面でも少し違いがあります。詳しくは Amazon Elasticsearch Service ドメインの VPC サポート の「制約事項」の項をご覧ください。

で、ここからお話するのは、この「制約事項」の項は書かれておらず、その次の「VPC ドメインのアクセスポリシーについて」の項でわずかに触れられている(しかし結構重要な)認証・認可についての制約事項の話です。

注記

セキュリティグループには IP ベースのアクセス権限ポリシーですでに強化されているため、VPC 内に存在する Amazon ES ドメインに IP ベースのアクセス権限ポリシーを適用することはできません。パブリックエンドポイントを使用する場合、IP ベースのポリシーを引き続き利用できます。

Amazon ES が提供する認証・認可

Amazon ES では、ドメインに対して、セキュリティポリシーとセキュリティグループを設定できます。セキュリティグループは、VPC アクセスの場合のみ設定できます。

さらに、ドメインに対するセキュリティポリシーには、以下の3種類を利用できます。公式ドキュメントでは Amazon Elasticsearch Service の Identity and Access Management に詳しく書かれています。

  • リソースベースのポリシー
    • リクエストの送信先 URL(特定インデックスの URL も指定可能)
  • アイデンティティベースのポリシー
    • リクエストの送信元 IAM ユーザーまたは IAM ロール
  • IP ベースのポリシー
    • リクエストの送信元 IP アドレス

そして、さっき上で引用したように、VPC アクセスの場合は IP ベースのポリシーは使えません。

この関係を図に表すと、以下のようになります。

f:id:muziyoshiz:20191130141129p:plain
Amazon ES の認証・認可

これを見て「なるほど、じゃあパブリックアクセスと VPC アクセスの認証・認可機能は同等なんですね。よかったよかった」と思われましたよね。僕も最初そう思いました。でもそうじゃない、そうじゃないんですよ……。

パブリックアクセスの場合

リソースベース、アイデンティティベース、IP ベースのポリシーは組み合わせて使えます。また、複数のステートメントを並べて書くこともできます。

例えば、「すべてのユーザに test-index の読み込みを許す」かつ「IAM ロール "power-user-role" を持ち、送信元 IP アドレスが 192.0.2.0/24 のユーザに対してのみ、すべての操作を許す」というセキュリティポリシーは、以下のように書けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:es:ESHttpGet"
      ],
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/power-user-role"
      },
      "Action": [
        "es:*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*"
    }
  ]
}

この関係を図に表すとこうなります。

f:id:muziyoshiz:20191130143201p:plain
パブリックアクセスの場合

VPC アクセスの場合

リソースベース、アイデンティティベースのポリシーは組み合わせて使えますが、IP ベースのポリシーは使えます。また、それとは独立に セキュリティグループも設定することができます。つまり図にするとこうなります。

f:id:muziyoshiz:20191130143330p:plain
VPC アクセスの場合

どうですか?

セキュリティポリシーとセキュリティグループは独立なので、例えばこの図でいうと「ステートメント1 AND セキュリティグループ1」という横の繋がりは強制できません。つまり、さっきパブリックアクセスの例に挙げた、以下のようなアクセス制御はできません。

「すべてのユーザに test-index の読み込みを許す」かつ「IAM ロール "power-user-role" を持ち、送信元 IP アドレスが 192.0.2.0/24 のユーザに対してのみ、すべての操作を許す」

IP アドレス以外の認証・認可方法は AWS 署名しかない

Oh... じゃあ仕方ない、VPC アクセスを使う場合は IP アドレスでユーザを識別して認可するのは諦めよう!と考えたとします。すると次に出てくるのは AWS 署名の問題です。

Amazon ES は、IP アドレス以外の認証・認可方法として、AWS 署名のみを許可しています。OSS 版や Elastic Cloud は Basic 認証に対応していますが、Amazon ES は対応してません。 Basic 認証は X-Pack の機能ですが、いまや OSS 版でも使えるというのに!(Security for Elasticsearch is now free | Elastic Blog

認証方法を強制的に IAM に統一できる、というのはもちろん強いメリットと言うこともできます。認証情報は集中管理できたほうがいいですよね。しかし、自分は実際に使ってみて、3つの問題を感じました。

まず1つ目は、Elasticsearch の REST API(以下、Elasticsearch API)の呼び出しも AWS 署名する必要が生じる ことです。

こう言うと、詳しい方は「aws コマンドには es サブコマンドがあるじゃないか」と言うかもしれません。確かに、Amazon ES のドメインを操作するための、AWS が提供する API の呼び出しは、aws コマンドで実行できます。だから、AWS 署名を意識する必要はありません。

しかし、Elasticsearch API は aws コマンドの範囲外です。もちろんライブラリを使えばそういうコードは書けますが、運用中は REST APIs を色々駆使したくなります。各 API に対応するコードを書くのかと言われるとちょっと……。

2つ目は、IAM ユーザや IAM ロールの設定範囲が、Elasticsearch に対して与えたい権限と必ずしも一致しない場合がある ことです。

例えば、既存の EC2 インスタンスに、Amazon ES へのアクセスを新たに追加したい場合に、「インスタンス1にはインデックスAへのアクセスを許可し、インスタンス2にはインデックスBへのアクセスを許可したい」と思ったとします。その場合、IAM ロールの付け替えが必要になります。既存の IAM ロールの ARN をあちこちから参照していたりしたら、付け替えは地獄の作業になります。

そして3つ目は、AWS 署名を必須にすると Kibana を使うために Cognito が必須になる という問題です。

Amazon ES では Elasticsearch API と Kibana のエンドポイントの FQDN は同じです。リソースベースのポリシーはリクエストの送信先 URL なので、当然 Kibana にも影響します。しかし Web ブラウザは(当たり前ですが)HTTP リクエストに AWS 署名を付ける機能なんて持ってません。

じゃあどうしたらいいの?というと、AWS は「Amazon Cognito を使用して Kibana のユーザー名とパスワードを管理する機能」をオプションとして提供しています。

docs.aws.amazon.com

Kibana へのアクセスを認証するためだけに、Cognito のユーザープールやら ID プールやらの設定をしなきゃいけないんですか?? ちょっと、やりたいことに対して Cognito の機能は過剰すぎませんかね……。

Elasticsearch API へのリクエストを AWS 署名する

そろそろ「そこまでして Amazon ES 使うの? Elastic Cloud で良くない?」という声が脳内に直接聞こえてきたのではないでしょうか。とはいえ、AWS ですぐ使えるのはやっぱり便利なので Amazon ES で我慢しよう、という判断をしたとします。

色々調べた結果、AWS 署名についてはこうするのが良いだろう、という自分なりの答えは出たので以下にてご紹介します。もっといい方法があったらぜひ教えてください。

プログラムから Elasticsearch API を呼ぶ

プログラムから Elasticsearch API を呼ぶなら、各種ライブラリが AWS クレデンシャルの取得に対応しているので、それを使うのが一番楽です。

EC2 インスタンスや Lambda 関数でプログラムを動かすなら、IAM ロールに対してアクセス権限を与えれば、ほとんど何も意識せずにコーディングできます。以下のページに公式のサンプルコードがあります。

docs.aws.amazon.com

より使いやすいライブラリもあります。例えば、Scala 用には elastic4s があります。

github.com

Python でのやり方についてはこちらで詳しく説明されていました。

dev.classmethod.jp

IAM ロールの設定範囲が Elasticsearch に対して与えたい権限と一致しない場合は、何の権限もない IAM ユーザを Amazon ES 専用に作るのが良いと思います。

コマンドラインから Elasticsearch API を呼ぶ

Elasticsearch を運用する際には、コマンドラインから curl を使って、REST APIs にある APIs を呼び出したいです。Amazon ES の管理コンソールは Elastic Cloud のものほどリッチではないので尚更です。しかし、curl には AWS 署名機能はありません。

そこで代替手段を色々探したところ、awscurl が、Elasticsearch APIs の利用に必要な機能をすべて備えていました。

github.com

ただし、awscurl の v0.17 までは日本語を含むリクエストの送受信に対応していませんでした。プルリクを送って対応してもらったので、v0.19 以降であれば大丈夫です*2

実際に使う人向け:awscurl に関するもうちょっと詳しい話

awscurl は便利なのですが、一時的セキュリティ認証情報 をサポートしていませんでした。だから、例えば Amazon ES 管理用の EC2 インスタンスを立てて、そこでコマンド実行したい、という場合には不便です。

もう少し詳しく話すと、AWS CLI の動作については AWS CLI の設定 の「構成設定と優先順位」に記載があります。このなかの「6. インスタンスプロファイル認証情報」のサポートに当たるものが awscurl にはありませんでした。

そこで、僕は管理用サーバの /usr/local/bin/awscurl-on-ec2 に、awscurl をラップするシェルスクリプトを置きました。

#!/bin/env bash

ROLE_NAME=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/`
CRED=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE_NAME}`
AWS_ACCESS_KEY_ID=`echo $CRED | jq -r ".AccessKeyId"`
AWS_SECRET_ACCESS_KEY=`echo $CRED | jq -r ".SecretAccessKey"`
AWS_SESSION_TOKEN=`echo $CRED | jq -r ".Token"`

awscurl "$@"

また、awscurl-on-ec2 コマンドの実行時に Endpoint URL をいちいち調べるのは面倒なので、作業用サーバの環境変数に設定しました。

awscurl と curl を比べて、使いやすい点・使いづらい点は次のような感じです。

  • curl より使いやすい点
    • ボディに json を含めるために -H 'Content-Type: application/json' を指定する必要がない
    • 邪魔な表示を消すために -s を指定する必要がない
  • curl より使いづらい点
    • AWS 署名を取得するサービスを特定するために、常に --service es を指定する必要がある
      • awscurl-on-ec2 のようなラッパーのなかで、デフォルトで --service es を付けてもいいと思います
    • AWS 署名を取得するリージョンを特定するために、常に --region リージョン名 を指定する必要がある
      • こちらも、使うリージョンが固定なら、ラッパーに含めてもいいと思います
    • ステータスコードを取得したいときに -w '%{http_code}' が使えない
    • 2xx 以外のときは例外がスローされる(インデックスの存在確認をするときなど、4xx が返されるのが正常な場合もある)

まとめ

今回は Amazon Elasticsearch Service(Amazon ES)を実際に使ってみて、認証・認可周りで困ったことと、どうやって無理やり使い続けているかを紹介しました。長々と書きましたが、まとめるとこんな感じです。

  • Amazon ES にはパブリックアクセスと VPC アクセスがある
  • パブリックアクセスと VPC アクセスでは IP アドレス認証の動作に違いがあり、VPC アクセスのほうが不便
  • Basic 認証は使えなくて、AWS 署名を使う必要がある
  • AWS 署名と Kibana を両方使いたいなら Cognito を強制される
  • AWS 署名ありで運用する場合は awscurl が便利

僕と同じく、Amazon ES を使う決心をした人は頑張りましょう! そしてもっといい方法があったら誰か教えてください!(切実)

更新履歴

  • 2019-12-03:awscurl のバージョンアップに伴って、日本語対応に関する記載を修正しました。

*1:昔は Elastic Co. だったと思うのですが、いまは Elasticsearch B.V. になっている?

*2:v0.18 は? v0.18 は僕のプルリクに別のバグが含まれていて、v0.19 で bugfix リリースしてもらってました。申し訳ない……。

「サテライトロッキー」の新バージョン「Satellite V2.0」が B-PUMP などのジムにも多数対応し、ムービーの共有機能も追加!

「サテライトロッキー」改め「Satellite V2.0」とは?

去年の10月10日に、「Rocky」というボルダリングジムが、「サテライトロッキー」というアプリを初めてリリースしました。

「サテライトロッキー」は、それまでに他のジムが提供していたアプリ(会員証程度のもの)とは一線を画していて、当時あまりにも感動してブログ記事を書いたりしました。

muziyoshiz.hatenablog.com

あれから約1年経った今月の10月23日、このサテライトロッキーが大幅にリニューアルされて、名前も「Satellite V2.0」に変わりました!

このアプリも期待を上回る素晴らしさだったので、今回改めて紹介記事を書いてみたいと思います。

(「サテライトロッキー」でググると以前のブログ記事が結構上位に出てしまうので、そのアップデートという気持ちもあり……)

そもそもボルダリングって何?

以前のブログ記事の冒頭で、「ボルダリングって何?」って方向けにボルダリングの軽い解説も書いてます。もし興味あればこちらをどうぞ。

最近だと「フリクションガール」というボルダリング漫画があって、こちらもおすすめです。ガチのクライマーの方が書いていて、品川ロッキーも取材協力してます(出てくるジムが思いっきり品ロキ)。このジムは初心者向け課題も多くておすすめですよ。

f:id:muziyoshiz:20191027101203j:image:w200

サテライトロッキーから引き継がれた基本機能

Satellite V2.0 の話に戻ります。

僕が思うサテライトロッキーの基本機能は以下の3つなんですが、Satellite V2.0 もこれらの機能をすべて持っています(詳しくは以前のブログ記事を)。

  • 機能1. 完登した課題を記録して、あとから写真込みで確認できる
  • 機能2. 全来店者でのランキングを確認できる
  • 機能3. 他のクライマーをフレンド登録して、フレンドのチャレンジ結果も確認できる

f:id:muziyoshiz:20191026224732p:plain
Satellite V2.0 の基本機能

また、ブログ記事を書いたあとのアップデートで、以下の機能もサテライトロッキーに追加されていました。これらも Satellite V2.0 に引き継がれています。

  • 来店回数や月間ランキングに応じたポイント付与機能
  • 会員証機能(会員番号のバーコード表示)
  • YTM(有酸素トレーニングモード) … 指定した級の課題がランダムに10個選ばれ、それを1時間以内に完登することを目指すモード

Satellite V2.0 での新機能

新機能1. ロッキー以外のボルダリングジム、クライミングジムにも対応!

リリース時点で、荻窪 B-PUMP、横浜 B-PUMP、Base Camp 全店舗といった有名ジムに対応していました。また、リリース後も続々と対応店舗を増やしているようです。

f:id:muziyoshiz:20191026225029p:plain
全国の Satellite 対応ジム

しかも、今回からはリードにも対応! 例えば Base Camp 入間店を見るとリードの課題も表示されるようになっています。

f:id:muziyoshiz:20191026225343p:plain f:id:muziyoshiz:20191026225423p:plain
Base Camp 入間店のリード課題

Satellite の公式サイト を見ると、月額 7,980 円/1店舗 という低価格でジムの囲い込みを進めているようです。課題の写真をアップロードする工数がネックになりそうですが、そこも店舗向けマニュアルで PicsArt を使った方法を丁寧に解説してて手厚さを感じました(なぜか店舗向けマニュアルにまで目を通してる人)。

新機能2. ムービーリンク機能で、完登した課題の Instagram 動画などを共有できる!

これは前からずっと欲しくて、1年前のサテライトロッキーの紹介ブログにも書いていた機能!

自分が完登した課題の一覧から、「動画を追加する」リンクをクリックすると、Twitter や Instagram のリンクを追加できます。嬉しくて、Instagram にアップロードした過去1年分の動画を一気に登録しちゃいました。

f:id:muziyoshiz:20191026230257p:plain
ムービーリンクの追加

登録したムービーは、各ユーザーのプロフィール画面の「ムービー」から確認できます。

f:id:muziyoshiz:20191026230451p:plain
過去に登録したムービーの一覧

また、「この課題をクリアした人の動画を参考にしたい!」といったときに、課題を完登したユーザーの一覧から「ムービーリンク付きユーザー」を探せるようになりました。

f:id:muziyoshiz:20191026230622p:plain
課題のページに表示されるムービーリンク付きユーザー

これまでは、完登動画を探したかったら Instagram で店舗のタグ(#宿ロキ とか)で検索したうえで、目当ての課題をクリアしてる動画を目視で探すしかなくて、なかなかつらみがありました。それと比べると、この Satellite の機能は断然便利です!

その他の細かな改善

その他の機能としては、バッジ機能も追加されました。

これはざっくりいうと「○級の課題を△△個以上完登!」とか「○級の課題をすべて完登!」などの条件でバッジをもらえるという機能です。(一定期間で課題は入れ替わってしまうから)特定の級をすべて完登しようとすると意外と苦戦するので、これは新たな目標になりそうです。僕はまだロッキー新宿曙橋店の3級全完登できてないので、それを目指してがんばります……。

他の細かな UI 改善としては、会員証の表示画面で、画面の明るさが自動的に強くなるようになりました。いままでは、バーコードリーダーでの読み込みが悪いときに、手動で明るさを変える必要があって手間でした。これは細かい点ですが嬉しい改善です。

f:id:muziyoshiz:20191026230754p:plain
過去に取得したバッジの一覧

今後のアップデートで予定されている機能

Satellite の公式サイト にて、Rocky の General Manager 竹内俊明さんが今後のアップデートに関してコメントされてます。

すでに物凄い多機能なアプリですが、次の大きなアップデートである「バトルモード」「トレーニングログ」ではクライミングジム界に革命をもたらす機能の提供を予定しております。

どういう機能なんでしょう……?

勝手に予想すると、「バトルモード」は大勢でコンペみたいに、一定時間で何課題クリアできるか競うようなモードでしょうか? 「トレーニングログ」はトレーニングボードなどを使った筋トレ回数を記録する機能とか? アップデートが今から楽しみです。

ちょっと不満なところ

色々紹介しましたが、最後にちょっと不満なところをいくつか。とはいえ UI に関する細かいところだけなので、今後のアップデートで直ってほしいなと……。

ムービーリンク機能の動線がまだ少しおかしい

新しく追加されたムービーリンク機能で、動線がまだ少しおかしいところがあります。

まず、ムービーリンクの追加場所が少し分かりづらいです。課題を完登したら「店舗」→「セット」→「級」と表示して、課題の左にある ○ をクリックして完登済みのチェックをつけることができます。ただ、この画面からムービーリンクを追加することはできなくて、一旦自分のプロフィールに戻って、「完登した課題の一覧」からその課題を探し直す必要があります。これが最初なかなか見つけられませんでした。

あと、他のユーザーのムービーが見たいときに、「ムービーリンク付きユーザー」から探せるよ、という話をしましたが、なぜかこの画面から直接ムービーのページに移動できません。

f:id:muziyoshiz:20191026231752p:plain
なぜかムービーに直接飛べない

そのため、一旦その人のプロフィールを表示してから、「ムービー」を選んで、見たい課題を改めて探す必要があります。これは本当にどうにかならないでしょうか……。

タップできる箇所が分かりづらい

サテライトロッキーのときは白背景だったものが、Satellite V2.0になったタイミングで黒背景になったことが原因かもしれませんが、タップできる箇所が分かりづらいです。

特にムービーリンク関係が厳しくて、例えば以下の「動画を追加する」リンクのタップできる箇所がとても狭いです。この範囲外をクリックすると、課題を完登したユーザー一覧が表示されてしまい、(Android の場合)そこから「戻る」ボタンを押すと「完登した課題の一覧」の先頭まで戻されてしまいます。これは、過去のムービーリンクを追加するときに何度も引っかかってストレスでした。ぜひ改善をお願いします……。

f:id:muziyoshiz:20191026232405p:plain
厳しいタップ範囲(ムービーリンクの追加の場合)

ロッキー独自の番号システムのサポートがなくなった

ロッキーではもともと、すべての課題に異なる番号が、難易度順に振られていました。ロッキー以外のジムにも対応するために仕方なかったのだと思いますが、Satellite V2.0 からはこの番号の表示機能がなくなっています。

これは若干不便になったんですが、その代わりに「課題一覧で写真が表示されるようになった」「新しい課題が NEW と表示されるようになった」という改善も入っているので、実際使うとそこまで問題にはなりませんでした。

f:id:muziyoshiz:20191026233240p:plain
同じ級の課題はすべて同じ番号(ポイント)

まとめ

Satellite V2.0 は、もともと非常に高機能だったアプリ「サテライトロッキー」を順当に進化させて、ロッキーという1つのジムに収まらない、今後の可能性を感じさせるアプリになりました。これからボルダリングを始める人には、ぜひこの「サテライトロッキー」で近場のクライミングジムを探して、ボルダリングに挑戦してみてほしいです!

インストールは以下のツイート内のリンクからどうぞ。