無印吉澤

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

ボルダリングジム Rocky がリリースした新アプリ「サテライトロッキー」がすごい！

Bouldering
f:id:muziyoshiz:20181027214926p:plain

去年の8月に同僚から誘われてボルダリングを始めて、いまは週2でジムに行くくらいハマっています。具体的に言うと、無意識にこんなこと言い出してしまうくらいハマってます。

一応IT業界の人間なので、ボルダリングをもっと楽しむのに使えるサービスやアプリって無いのかな……と色々探してるんですが、意外といいのがありません。

そんな中、今月の10日に「Rocky」というボルダリングジムが、「サテライトロッキー」というアプリをリリースしました。このアプリはとても良くできていて、今後ボルダリングジムがこぞって提供し始めるような、デファクトになる可能性を秘めていると思います。

そこで今回は、ボルダリングにハマるとどういうサービスやアプリが欲しくなるかと、その観点から見て「サテライトロッキー」がどれくらいイケてるアプリなのか、をご紹介します。

ボルダリングとは？

ボルダリングを知らない人向けに、話の前提として簡単に説明します。

ボルダリングは、高さ5m前後の壁（屋内）や岩（屋外）を、予め決められたスタート地点からゴール地点まで登って、達成感を味わうスポーツです。細かいルールは色々ありますが、基本はそれだけのシンプルなスポーツです。

実際に体験してもらわないと面白さを伝えるのは難しいので、とりあえず1回、経験者と一緒にジムに行ってやってみてください。僕の知り合いの人なら、呼んでもらえればホイホイついていくのでぜひ行きましょう。

ボルダリングにハマると欲しくなるもの

ボルダリングにハマると、「もっと難易度の高い課題（※ボルダリング用語でコースのこと）を登りたい」と思う一方で、「最近あまりうまくなってない気がする」という壁にもぶつかるものです。

そうなると、だいたい以下の2つのニーズが出てきます。

  • うまい人がどうやってるのか知りたい
  • 自分の成長を記録したい

「サテライトロッキー」が出る以前に、いままで僕がどういうことを試してきたかを、一例として書いていきます。

うまい人がどうやってるのか知りたい

まずはちゃんと知識を得たい、ということで本を読み漁りました。自分で買ったり、会社の同僚（ボル部の部長）から借りたりして読んだなかで、特に参考になったのはこのあたり。

インドア・ボルダリング練習帖 (RS Books)

インドア・ボルダリング練習帖 (RS Books)

完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版

完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版

パフォーマンス・ロック・クライミング

パフォーマンス・ロック・クライミング

  • 作者: デイルゴダード,ウドノイマン,Dale Goddard,Udo Neumann,森尾直康
  • 出版社/メーカー: 山と溪谷社
  • 発売日: 1999/04/01
  • メディア: 単行本
  • 購入: 2人 クリック: 8回
  • この商品を含むブログ (4件) を見る

Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!

Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!

  • 作者: 中根穂高(ジャック中根),江崎善晴
  • 出版社/メーカー: 山と渓谷社
  • 発売日: 2018/01/11
  • メディア: 単行本（ソフトカバー）
  • この商品を含むブログを見る

しかし、関連書籍はあまり多くないですし、一通り読み終わると「用語は覚えたけど、どういうときにどのムーブを使えばいいのかよくわからない」という状態になりました。

ブログやウェブサイトも探したのですが、初心者の役に立つようなものは山と溪谷社の CLIMBING-net くらい。じゃあ動画を、と思って YouTube で「ボルダリング 解説」などで検索しても、意外とあまり動画がありません。

ボルダリング関係のちょっと変わった動画サイトとして、OnlineObservation というサイトがあります。このサイトは、課題を3Dモデルで確認した上で、クリア動画も見られるのですが、作るのが手間だからか、動画数が少ないのが難点です。

最終的に「これは良い」と思ったのは、自分が行ったジムの名前で YouTube や Instagram を検索して、自分が登れなかった課題を登ってる動画を探す という方法でした。これなら、自分が一度トライしているのでどういう課題かわかるし、自分が登れなかった部分に絞って何回も再生したりできて、勉強になります。

自分がよく行くジムに行っているユーザーの YouTube チャンネルをチャンネル登録したり、Instagram でフォローするのも良いと思います。おかげで、最近は YouTube と Instagram がすっかりクライミング動画アプリになってしまいました……。

自分の成長を記録したい

うちの会社と1つ上の階の会社のメンバで「ボル部」を作って、毎週水曜に3〜5名でボルダリングジムに行ってます。お互いに動画を撮って Google Photo のアルバムで共有しているので、それが成長記録みたいな感じになっています。

ただ、そんなに常にお互いの動画を撮ってられないし（そんなことより登りたいし）、細かい成長度合いはよくわかりません。

そこで、最近になって自分のトレーニング内容を日誌に記録し始めました。これは書籍（「パフォーマンスロッククライミング」や「Jack中根のクライミング道場」）で推奨されていた方法です。主に以下のようなことを書いています。

  • 挑戦した課題の難易度や、その数
  • 完登した課題数
  • フラッシュした（1回で完登した）課題数
  • その日の体の調子

こういうのを記録する良いアプリがあればよかったんですが、結局普通の手帳に書いてます。

アプリ「サテライトロッキー」の機能とイケてるところ

そこで、今回の「サテライトロッキー」です。

「構想から開発、完成まで2年」と宣言するだけのことはある、よくできたアプリになっています。正直に言うと、アプリとしての使い勝手にはまだ改善の余地が多いのですが、Rocky というボルダリングジムのシステムと非常によく噛み合ってます。

公式サイトにも説明はあるのですが、僕の注目するポイントからも機能紹介します。

www.rockyclimbing.com

機能1. 完登した課題を記録して、あとから写真込みで確認できる

ロッキーの店舗でサテライトロッキーを起動すると、自分が完登した課題を登録できる「チャレンジモード」に入れます。店舗にいるかは GPS で判定されます。このチャレンジモードで登録した結果は、あとからいつでもアプリで確認できます。

会員証代わりにアプリを提供しているボルダリングジムはたまにありますが、まずこんな記録機能自体がいままでに無いものです。ロッキーは、サテライトロッキーの提供以前から、すべての課題に対して、難易度順に一意な番号を振っています。そのシステムが元からあるからこそできる。これは結構すごいことです。

f:id:muziyoshiz:20181027215553j:plain:w640

それに加えて、完登した際に、それがフラッシュかどうかも記録できます（フラッシュの場合はカミナリのアイコンが表示されます）。フラッシュかどうかをクライマーは重視するので、そのあたりわかってる人がアプリ開発してるの良いですね。

f:id:muziyoshiz:20181027220030j:plain:w320

さらに、ここから課題番号を選ぶと、なんとその課題の写真も見られます。いままでは気になる課題を自分で撮影したりしてましたけど、その手間もなくなるなんて……。この画像の用意はさぞかし大変だろうと思いますが、ここまで徹底すると他のジムには簡単に真似できない価値になってます。

f:id:muziyoshiz:20181027220059j:plain:w320

機能2. 全来店者でのランキングを確認できる

先ほど書いた通り、ロッキーではすべての課題に対して、難易度順に一意な番号を振っています。自分が完登した課題の上位10個の合計値でランキングを競う「集大成」というシステムがあり、ランキングの集計結果が約2ヶ月に1回公開されています。

www.rockyclimbing.com

これと同じシステムがサテライトロッキーにも実装されています。違うのは、ランキングの集計が1日1回に変わったこと。

いままでは2ヶ月に1回の更新だったので、他のクライマーとのポイント差を意識するようなことはあまりありませんでした。しかし、頻度が上がったことで、自分と近いレベルの人（例えばよく一緒にジムに行ってる友達）との接戦を楽しんだりできそうです。

これは、アプリで新たに実装した機能というよりは、もともとロッキーというジムに存在していたシステムをアプリに導入したものです。この機能も、他のジムが真似しようとしたら、ジムのシステムから見直す必要があり、容易ではなさそうです。

f:id:muziyoshiz:20181027220748j:plain:w320

機能3. 他のクライマーをフレンド登録して、フレンドのチャレンジ結果も確認できる

最後に、このサテライトロッキーには SNS のようなフレンド機能があります。現状では、フレンド（フォローした相手）の完登記録を確認したり、次の来店予定日を共有できたりするようです。

サテライトロッキーの開発側は、グレードの高いクライマーをみんながフォローするようになり、グレードが上がるほどフォロワーが増えてモチベーションが上がる、といったことを考えているのかもしれません。

僕のような普通のクライマーにとっては現状ではフォロワーとフォロイーを一覧できる程度ですが、この機能も、発展させていけばかなり面白くなるんじゃないかと思っています。

f:id:muziyoshiz:20181027221254j:plain:w320f:id:muziyoshiz:20181027221305j:plain:w320

サテライトロッキーへの要望いろいろ

そんな感じで非常に良いサテライトロッキーなんですが、もっとこうだったら、という点もいくつかあります。

要望1. 挑戦したけど完登できなかった、という記録も残せるようにしてほしい

サテライトロッキーは「自分の成長を記録したい」というニーズをかなり満たしてくれているのですが、現時点では「挑戦したけど駄目だった」記録は残すことはできません。

ロッキーには半年以上通っていますが、3回目かの来店でやっと完登できた課題や、2ヶ月以内に完登できずに壁を張り替えられてしまった課題なんかもありました。そのときの課題も、記録に残しておいてあとから見返せるとちょっと嬉しいです。

要望2. 課題から Youtube, Instagram 動画へのリンクを張れるようにしてほしい

上記のように記録機能は充実している一方で、「うまい人がどうやってるのか知りたい」というニーズはまだあまり満たしてくれません。

せっかく他のクライマーの完登記録を見る機能があるので、そこから一歩進んで「この課題の完登動画」へのリンクを登録できるようにしてほしいです。例えば、自分が完登した課題を選択したら、そこから Instagram に完登動画を登録できる、とか。

課題と動画を紐付けられれば、課題のページにその課題の完登動画をリストアップできるようになります。そうしたら、クリアできない課題があったらサテライトロッキーを開いて完登動画を見て再チャレンジ……ってことがその場ですぐできるはず。

あと、現在でもプロフィールに Instagram アカウントへのリンクを設定できるようになってますが、YouTube チャンネルへのリンクも設定できるといいんじゃないでしょうか。

要望3. フォロー関係を使って各種 SNS に投稿された動画を通知してほしい

要望2の延長で、もしフレンドが完登動画を登録したら、それを通知してもらえると嬉しいです。

今でも Instagram アカウントでフレンドを直接フォローしてしまえば、もちろん動画は見られます。ただ、Instagram にはクライミング関係以外にもいろいろ投稿するのが普通なので、クライミング動画を見たいときはサテライトロッキーを見る、という感じで使い分けられるといいんじゃないでしょうか。

まとめ

サテライトロッキーは、「自分の成長を記録したい」というクライマーのニーズを満たしてくれるアプリです。また、フレンド機能が今後発展していくと、「うまい人がどうやってるのか知りたい」というニーズまで満たしてくれる可能性も持っています。

この記事を読んでちょっとでも興味をもってくれたら、ぜひ以下の公式サイトからサテライトロッキーをインストールしてみてください。そして一緒にボルダリングしましょう！（ダイレクトな勧誘）

2019-10-27追記

サテライトロッキーのアップデート版「Satellite v2.0」に関する記事はこちら。

muziyoshiz.hatenablog.com

SRE Lounge #5 にて Backlog における SRE の事例について講演しました

SRE
f:id:muziyoshiz:20180927232609p:plain

僕は去年の8月にヌーラボに入社して、そこから Backlog の SRE として働いています。

SRE としての経験は約1年なのですが、ちょうどサービスが成長し、会社もエンジニアを積極的に採用して拡大している時期だったこともあり、色々な経験ができました。そのなかで、SRE の難しさ、SRE の組織の問題にも直面してきました。

このあたりの経緯を整理して話すだけでも SRE にとって面白い話になるのではないか、と思い、今回の SRE Lounge #5 では「Backlog における SRE の事例 〜プロダクトの成長のために SRE はなにをすべきか〜」というタイトルで発表させていただきました。

sre-lounge.connpass.com

発表スライドはこちらです。

発表のときは冒頭で説明したのですが、これがベストプラクティスと言うつもりは全然ありません。僕らもまだ悩んでいる最中の問題を、その背景も含めて（話せる範囲で）丁寧にまとめて説明することで、他社の SRE の方々からご意見をいただきたい……という趣旨の発表でした。

その後の質疑応答や、Twitter での反響を見た限り、とても好評だったようでホッとしています。「SREの業務範囲は放っておくと再現なく広がっていく」、「SRE を組織の中でどう配置すべきかはすごく難しい」といった問題意識は多くの方に同意してもらえたようです。

詳しくはスライドの方を見てもらうとして、以下に当日の質疑応答や、懇親会で話したこと、今回のプレゼンの関連資料などをまとめておきます。

質疑応答

覚えている範囲でまとめておきます。発表直後でかなりテンパっていたので、質問者の質問や、僕の回答の表現は、実際に話されたものとは多少ズレているかもしれません。

  • Q) 開発チームはスクラムなどに従って開発していると思うが、SRE の仕事はその開発スパンには合わないのではないか。そこはどうしているか
    • A) 開発者と SRE で同じカンバンは共有しているが、SRE は独立して動いている。障害対応があるときはそれを優先し、それ以外のときは改善のタスクを取るとか
  • Q) SRE が開発チームに入ることで良くなる面があったのはわかった。逆に、SRE が入ることで悪くなった面はあるか？
    • A) 開発者の側としては割り込みが増えたと感じているかもしれない。エスカレーションが早くなる分、「調べたけど問題なかった」というハズレも増える
  • Q) チームは拠点ごとに分かれているか？ このチームは福岡に全員いる、など
    • A) ヌーラボはリモートでのコラボレーションを促進するサービスを提供していることもあり、複数拠点に分かれたチームはたくさんある。自分もそう。ただ、1拠点にまとまったチームもある
  • Q) Backlog の開発者の規模はどれくらいで、そのうち SRE は何名いるか
    • A) 開発者は30名前後と考えてもらえれば。SRE は講演でも話したとおり、現時点では4名
  • Q) SRE を採用するときに重視している点はあるか
    • A) 個人的には、技術力が高いこと、自分から問題を定義して仕事を作れること、チームをまたいで仕事をする必要があるのでそういうコミュニケーションを嫌がらないこと、の3点を重視している

懇親会で話したこと、質問を受けたこと

お話できたのは一部の方だけでしたが、SRE やインフラエンジニアが多い印象を受けました。ターゲットに沿った人がうまく集まっていて、SRE Lounge は SRE にとって良い議論・発表の場だと思いました。

オプトの渋谷さんの発表に対する質疑応答でも出ていた質問ですが、SRE は何人いたらいいのか？ 開発者に対する割合としてどれくらい必要なのか？ という質問は何度か受けました。北野さんがツイートしてましたけど、答えはまさにこれ（↓）ですね。何人必要かは、自分たちもまだ模索中です。

あとは、これから新しく SRE チームを作るとしたら何に注意すべきか、という相談も受けました。SRE という用語を生み出した Google 自身もそうですが、自社でサービスを開発・運用している組織でないと、SRE に適切なインセンティブをもたせることは難しいのではないか……というくらいしかわからないですね。僕も答えは持ってませんが、SRE チームをうまく構築するスキルをもったコンサルのニーズは高そうだなあと思いました。スクラムマスターとか技術顧問みたいな感じで。

関連資料

スライドの中で触れた、Backlog SRE による過去の発表資料、ブログ記事はこちらです。

speakerdeck.com

nulab-inc.com

この発表内容がまとまるまでの経緯

スタディスト（ヌーラボ東京事務所の1つ上のフロア）の北野さんから講演のお誘いを受けて、SRE について考え直すいい機会かな、と思ってとりあえずOKしたところから始まりました。

そこから、まずは入社時に聞いた SRE チームの歴史のメモからたたき台を作り、週一の SRE チーム定例で毎回レビューをお願いして、発表内容をブラッシュアップしていきました。そのおかげで発表内容がよくなっただけでなく、SRE チーム内で過去の経緯を共有したり、今後のあるべき姿を考えるいい機会にもなりました。

他の会社の SRE チームでも、同じように過去の経緯をまとめてみる（そして SRE Lounge で発表する）のはいいんじゃないかなーと思います。オススメです。

最後に、SRE Lounge 運営の皆さん、今回の会場をご提供くださったウォンテッドリー株式会社の皆さんに感謝します。僕も今後できるだけ SRE Lounge をお手伝いしたいと思います。また会場でお会いしましょう。

あわせて読みたい（2018-12-13追記）

この講演のときに時間不足で省いたサービスレベル管理の話を、ヌーラボブログに大ボリュームでまとめました。よかったらこちらもどうぞ。

nulab-inc.com

kintone devcamp 2018 にて AWS Lambda を使ったサービス間連携についてのハンズオンセッションを行いました

AWS Lambda Amazon API Gateway Serverless Framework Backlog
f:id:muziyoshiz:20180630010936p:plain

8/2(木) に開催された kintone devCamp 2018 にて、kintone と Backlog を API 連携させる方法についてのハンズオンセッションを実施しました。サイボウズの方から企画の提案があって、（資料を作りながら自分でも）手を動かしてみる良い機会と思い、引き受けさせていただきました。

kintone & Backlogハンズオン 〜利用シーンに応じたタスク管理ツールの使い分けをAPIで実現〜

目次はこんな感じ。90分のハンズオンセッションでした。

  • Backlogとは？
  • Backlogとkintoneの連携
  • Backlog APIによるサービス間連携
  • ハンズオン1. ノンプログラミングでの連携
  • AWS LambdaとFunction as a Service
  • ハンズオン2. AWSのサービスを用いた高度な連携

このハンズオンセッションは2部構成で、前半は kintone プラグインを使ったノンプログラミングでの連携。後半は AWS Lambda と Amazon API Gateway を使った連携でした。後半はスライドの p.94 からです。AWS Lambda だけ興味のある方は、そこから見てもらえれば。

スライドにはかなり細かく手順を書きましたし、ソースコードも GitHub で公開しているので、AWS Lambda を一度使ってみたい！という方は是非お試しください。

github.com

ちなみに、ハンズオン当日は、前半のハンズオンは7〜8割の参加者が設定完了して動かすことができたのですが、前半で時間を使いすぎて、後半はかなり駆け足で解説だけして終わってしまいました。それでも、後ほど頂いたアンケート結果で、8割近くが満足度「普通」以上の回答で一安心しました。

資料を作り始める前は、90分あれば余裕と思ってたんですが、実際に手を動かしてもらうハンズオンは時間調整が難しいですね……。次の機会があったらもう少し工夫します。

あわせて読みたい

最近書いた以下の記事は、このハンズオンの準備中に調べたことのまとめです。ハンズオンを触ってみる際は、こちらもあわせてご覧ください。

muziyoshiz.hatenablog.com

muziyoshiz.hatenablog.com

Amazon API Gateway で API (Webhook) の呼び出し元 IP アドレスを制限する

AWS Lambda Amazon API Gateway Serverless Framework
f:id:muziyoshiz:20180630010936p:plain

前回の記事では、Webhook の受け口を Amazon API Gateway で作る方法をまとめました。

muziyoshiz.hatenablog.com

この方法で作った API は、URLを知っている人なら誰でも叩けてしまいます。Amazon API Gateway は IAM や API キーでの認証をサポートしていますが、一般的な Webhook は指定された URL に POST を送るだけなので使いづらいです。

しかし、Amazon API Gateway のリソースポリシーを使うと、API の呼び出しを許可する IP アドレス（つまり Webhook の送信元 IP アドレス）を限定することができます。何も無いよりはずっと良いので、今回はこの設定方法をまとめておきおます。

Amazon API Gateway のリソースポリシー対応

昔の Amazon API Gateway には送信元 IP アドレスの制限機能はなく、Amazon API Gateway Lambda オーソライザー（カスタムオーソライザー）で自前で実装する必要があったそうです（※僕は使ったことないのですが、ググると出てきます）。

しかし、2018年4月2日に Amazon API Gateway が API リソースポリシーをサポート開始し、これで IP アドレス制限ができるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2018/04/amazon-api-gateway-supports-resource-policies/aws.amazon.com

以下の AWS のドキュメントに、リソースポリシーの例が掲載されています。

docs.aws.amazon.com

Webhook の場合は「送信元 IP アドレスを特定のサービスに限定する」ことができれば十分でしょう。例えば、Backlog というサービスでは以下のように Webhook を実行するサーバーの IP アドレス範囲を公開しています。

backlog.com

この Backlog の Webhook のみを受け取りたい場合、以下のようにリソースポリシーを書けば OK です（リージョンなどは伏せてます）。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": [
                "arn:aws:execute-api:region:account-id:api-id/*"
            ],
        },
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": [
                "arn:aws:execute-api:region:account-id:api-id/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "52.199.190.133/32",
                        "54.238.59.48/32",
                        "54.65.8.249/32",
                        "52.192.161.184/32",
                        "52.68.222.36/32"
                    ]
                }
            }
        }
    ]
}

Serverless Framework のリソースポリシー対応

Serverless Framework も、2018年4月7日リリースのバージョン1.28でリソースポリシーに対応しました。今では、serverless.yml 内でリソースポリシーを記述できます。

github.com

簡単な例が公式ドキュメントに載っています。

serverless.com

serverless.yml に以下のように書くと、先ほどの Backlog の例に挙げたリソースポリシーが自動設定されます。"103.79.14.0/24" のような範囲指定も可能です。

provider:
  name: aws
  runtime: nodejs8.10

  resourcePolicy:
    - Effect: Allow
      Principal: "*"
      Action: execute-api:Invoke
      Resource:
        - execute-api:/*/*/*
      Condition:
        IpAddress:
          aws:SourceIp:
            - "52.199.190.133"
            - "54.238.59.48"
            - "54.65.8.249"
            - "52.192.161.184"
            - "52.68.222.36"

設定結果は、以下のように AWS コンソールで確認できます。

f:id:muziyoshiz:20180729112632p:plain:w800

範囲外の IP アドレスからのアクセスはどのように拒否されるか

前回の記事で作った hello 関数で試してみます。

hello 関数は、以下のように JSON でメッセージを受け取って、文字列を付け足して返す関数でした。

$ curl -H 'Content-Type:application/json' -d '{"message":"world"}' http://localhost:3000/hello
{"message":"Hello world 2018"}

許可されていない IP アドレスから、この curl コマンドを実行すると、403 とエラーメッセージ（JSON）が返されます。

$ curl -v -H 'Content-Type:application/json' -d '{"message":"world"}' https://**********.execute-api.ap-northeast-1.amazonaws.com/dev/hello
*   Trying ***.***.***.***...
* TCP_NODELAY set
* Connected to **********.execute-api.ap-northeast-1.amazonaws.com (***.***.***.***) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.execute-api.ap-northeast-1.amazonaws.com
* Server certificate: Amazon
* Server certificate: Amazon Root CA 1
* Server certificate: Starfield Services Root Certificate Authority - G2
> POST /dev/hello HTTP/1.1
> Host: **********.execute-api.ap-northeast-1.amazonaws.com
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type:application/json
> Content-Length: 19
>
* upload completely sent off: 19 out of 19 bytes
< HTTP/1.1 403 Forbidden
< Content-Type: application/json
< Content-Length: 165
< Connection: keep-alive
< Date: Sun, 29 Jul 2018 02:08:33 GMT
< x-amzn-RequestId: 4ba819ee-92d4-11e8-a7e3-7feb0ae86886
< x-amzn-ErrorType: AccessDeniedException
< x-amz-apigw-id: KxIxOGMatjMFhWg=
< X-Cache: Error from cloudfront
< Via: 1.1 7b63dc372a4330b28d4dd1f11ec139a7.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: PPGEdw9vYkOwQejOGAztIO63Atb73po3rzaszbcRpJpXZEQbjVzPIg==
<
* Connection #0 to host **********.execute-api.ap-northeast-1.amazonaws.com left intact
{"Message":"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:ap-northeast-1:********3987:**********/dev/POST/hello"}

一度設定したリソースポリシーの削除方法

ここはまだ自分でもよくわかっていない部分です。

一度設定したリソースポリシーを消すために、以下のように resourcePolicy 以下をコメントアウトして sls deploy を実行しても、AWS コンソール上のリソースポリシーは削除されませんでした。

provider:
  name: aws
  runtime: nodejs8.10

#  resourcePolicy:
#    - Effect: Allow
#      Principal: "*"
#      Action: execute-api:Invoke
#      Resource:
#        - execute-api:/*/*/*
#      Condition:
#        IpAddress:
#          aws:SourceIp:
#            - "52.199.190.133"
#            - "54.238.59.48"
#            - "54.65.8.249"
#            - "52.192.161.184"
#            - "52.68.222.36"

また、AWS コンソール上で直接、以下のようにリソースポリシーを削除しても、IP アドレス制限は有効なままでした。Amazon API Gateway の設定を変更するだけでは駄目？ CloudFormation や CloudFront の設定も絡んでるんでしょうか？

f:id:muziyoshiz:20180729112647p:plain:w800

結局、以下のように、すべての IP アドレスを許可するリソースポリシーを設定したあとで、sls deploy を実行すると、IP アドレス制限を解除することができました。

  resourcePolicy:
    - Effect: Allow
      Principal: "*"
      Action: execute-api:Invoke
      Resource:
        - execute-api:/*/*/*