ReporterがAccessToken必須に変更になっていた

本日は、沖縄も台風日和で外が騒がしいです。 台風の目も過ぎて、台風も後半戦です。 さて、本題に。 モバイルアプリケーションのダウンロード数を取得し DBに格納するスクリプトをだいぶ前に作成したっきり放置していたのですが iOSで利用していたReporterの挙動が2017/08/10から変更になっていたようで。 Reporter User Guide - help.apple.com これまでのReporterは AppleIDとPasswordをReporter.propertiesに ベタ書きして利用しなければならなかったんですが、 AccessTokenの記載が可能になりました。 これは便利。 コマンドラインからもTokenの取得ができるのですが、 Webからも一応取得できるようです。 というかコマンドラインから取得したほうがめちゃ簡単です…w Webから取得する方法 iTunes Connect にログイン 「売上とトレンド」を選択 プルダウンから「レポート」を選択 「?」から「アクセストークンを生成」を選択 これでアクセストークンの生成ができます。 「?」ってUI的にはヘルプ感あるので、 ここからアクセストークンが生成できるとは思わず 探すのに苦労しました…(笑) おしまい。 »

沖縄でAWS SAA受験してきました(合格したよ)

去年4月にお仕事を始めてからAWSを少しずつ触るようになり、 自前でAWSアカウントを用意していろいろ遊んだりするようになったりと AWSはお世話になりっぱなしです。 AWSの勉強会とか参加していく中で、認定試験の存在も知りましたが その時は試験会場が東京、大阪、福岡くらいの3都市くらいしかなくて、 沖縄から受験するには一番近くて福岡まで遠征する必要がありました。 物理的な制約があるのでどうしようもない感じはするんですが、 東京とか行く機会があれば腕試しはしたくて Shownetで東京行った時も土日で空いてるところ探しても 運悪く見つからず諦めてました。 (ボランティアやってた時は全力で楽しんでたので、そんな余裕は無かったなと今になって思う^^;) とまあ、東京行く機会もほとんど無いので 受験はほぼほぼ諦めてたんですがそんな時に朗報が どうやら沖縄でも受験できるようになったらしい。 物理的な制約は無くなったので後はやる気だけ、 というかやる気は元々あったので 上のスライドを見たその日に勢いで受験申し込みしました。 受験日までにやったこと Qiitaとかいろいろなところで合格体験記書いてる人いますが、 実際やってることはあんまり変わらないはず。 合格する ことよりも これから先もAWSで楽しく遊べるようにいろいろなことを知る というのをモチベにやってました。 私自身はプレッシャーにすごく弱いので 合格しなきゃみたいな気持ちでやると確実に失敗するので あまり自分を追い詰めるような感じで目標は立てないようにしてます(笑) そのせいなのか、 個人的には勉強をしたというより遊んでいたっていう感覚に近かったです。 とりあえずノー勉で模擬試験を受験 今まで利用してきたサービスの見直し AWSのクラウドデザインパターンを読む Blackbeltの資料を読む サービスを利用する 気になったところは公式ドキュメントを読む 暇なときは問題集を眺める とりあえずノー勉で模擬試験を受験 お金はかかるけど模擬試験は受験しといたほうがいいです。 現状で何が理解できてて何が理解できてないのかが確認できるし、 問題がどういう感じで出されるのか UIはどんな感じなのか とか事前に分かるので これ受けてるか受けてないかは結構差が出ると思います。 模擬試験の注意事項にも書いてあるけど 問題の解答は貰えないので、解答は後で調べ直す感じで。 今まで利用してきたサービスの見直し 今まで利用してきたサービスはまず見直しました。 EBSはどのタイプを利用しているのか、 今利用しているインスタンスタイプは最適なものなのか、 ただEC2インスタンス建てて無いよねとか、 ELBはCLB,ALBどっちがお得に利用できそうかとか、 今使っているサービスがどう動いてて、他にはどういった機能があるのかとか 実際に試験を受けるまではここばっかり気にしてました。 AWSのクラウドデザインパターンを読む 実は一年以上前に買って積んでた本 Amazon Web Servicesクラウドデザインパターン設計ガイド いい機会なので1から読んでました。 デザパタはWikiのページもあるので、こっち読んでもいいはず。 知らなかったデザパタもあって結構勉強になりました。 デザパタさんありがとうございます。 Blackbeltの資料を読む Blackbeltの資料は1つ1つのサービスに対しスライドのボリュームがかなり多くて読み応えがあります。 »

IAM Roleで特定のS3バケットのみアクセスが可能なユーザを作成する

久々の更新。 昨日はネットワークスペシャリストを受験してきたけど散々でした… (ちーん IAMで特定のバケットのみRead Writeを許可するユーザを作成する必要があったのでその時のメモ。 ポリシを自分で書いちゃえばいけました。 例えばhogehogeというバケットに対してフルアクセスを許可したいときは { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3::hogehoge", "arn:aws:s3:::hogehoge/*" ] } ] } 後はユーザを作成して上記のポリシをアタッチするだけでOKです。 実は下記にポリシシミュレータがあって、ポリシの検証をができるらしい。 https://policysim.aws.amazon.com/home/index.jsp 上のポリシで検証したらFailed出てS3のアクセスができないよってログが出てたのだけれど、 個別バケットの場合は、ポリシシミュレータがFailedを返すようでした。 実際に上記のポリシをアタッチしたユーザでaws-cliコマンドを叩くとそのバケットだけにアクセスできました。 »

OWT2017(沖縄サテライト)に参加してきた

OWASP World Training Tour 2017 - owasp.orgに参加してきました。 参加といっても沖縄のサテライト会場でです。 配信チームの皆さま、そしてOWASP沖縄のリーダーさん取りまとめありがとうございます。 OWASP World Tourとは? 公式からの引用ですが アプリケーションセキュリティのアプローチには、あらゆる側面が含まれています。その問題の解決には、人、プロセス、および技術の視点で取り組むことが必要です。こうしたコンセプトを推進する一環として、OWASPは、SDLC全体にセキュリティを組み込むことを希望する開発者のための基本的なAppSecトレーニングを提供します。 OWASPさんは、世界中で利用されているソフトウェアに関わるセキュリティ品質を改善することにコミットしていて、 私もたまに提供されている資料を眺めたりとお世話になってます。 朝から18:30までと長丁場でした。 スピーカーさんたちの資料もOWASPのSpeekerDeckに全部上がってました. Opening OWASP Project Overview for Developers - 上野宣 OWASPさんで提供しているTool, Docについてざらっと紹介. 最近, 上野さんの本買って読んでます. Training Session 1 OWASP TOP 10を用いた脆弱性対応 - 安藤崇周 OWASP TOP10, Proactive Controlsの説明から. OWASP TOP10は見たことあるけど, Proactive Controlsまでは見たことなかった. 対応表が載っててどれがどれに対応しているのかが分かりやすかった. あとは、セキュリティ機能をゼロから開発していくのは時間の無駄だし, 自分だけでやっちゃうと設計・実装ミスは必ず発生するので, あるものを利用してそこにコミットを切っていくのが大事なのは理解できた. 脆弱性の対応と一口に言っても どこまでを要件として盛り込むか, どう設計するか, コーディングからテスト,脆弱性検査まで どうやっていくかは案件の規模や扱う情報に応じて異なるのでその辺は臨機応変に. 要件書も結構参考になるので、ここももう一度見よう ueno1000/secreq - github Session 2 最小権限の具体的な実現方法 - 長山哲也 最小権限の重要性と難しさについてでした。 »

GCPインスタンスのスナップショットを定期的に取得する

GCPインスタンスのスナップショットを定期取得・削除してみる GCPで動作するインスタンスのスナップショットはGCPのコンソールからポチポチやると 簡単に取れたり不要なものを削除したりできるのだけれど、毎日コンソールを開けて手でポチポチやるのは大変なので自動化する。 その時のメモ。 ServerlessFrameworkでは、GoogleCloudFunctionも対応してるのでこれでいけるんじゃないかと思ったのだがeventがhttpしか選択できず cron的な使い方ができないので断念。。。 Google Function Events - Serverless.com 楽に実装できそうなLambdaに逃げることに。 GCPを操作するライブラリはNodeJSで書かれたgoogle-cloud-nodeを使用しました。 GoogleCloudPlatform/google-cloud-node - Github 下記のドキュメントにサンプルコードがあるのでそれを利用してます。 スナップショットの作成 https://googlecloudplatform.github.io/google-cloud-node/#/docs/compute/0.7.1/compute/disk?method=createSnapshot スナップショットの削除 https://googlecloudplatform.github.io/google-cloud-node/#/docs/compute/0.7.1/compute/snapshot?method=delete 実際に書いたコード 328/gcp-backup-cron - Github 1つのプロジェクトだけで利用するのではなく、複数のプロジェクトにも使い回しができるよう プロジェクト情報やインスタンス名は全て環境変数(serverless.yml)に記載するように気を使ってます。 インスタンスのスナップショットはポンポン消しちゃって大丈夫なのかなって疑問に思ってたんですが、 削除時に依存関係のあるデータは全て次のスナップショットに移動されるそうです。 スナップショットを削除する - GoogleCloudPlatform »

S3 パフォーマンス改善

沖縄でもAWS 認定ソリューションアーキテクトが受験できるというのを先日知り、腕試しをしてみようと思い資料漁りをしてます。 そんな中、S3への大量のリクエストをさばくにはどうすればいいんだろうとか考えてました。S3っていつもデータぶん投げるためだけに使ってたし、勝手にスケールするんでしょ〜とか思ってたけど 大量アクセス時に負荷が高い場合の性能の引き出し方が載ってた。 http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/request-rate-perf-considerations.html S3のバックエンドでは、keynameでパーティションを分割してバケットリクエストの増加に耐えるようになっているみたい。こっちにも例が載ってた。 http://aws.typepad.com/aws_japan/2012/03/amazon-s3-performance-tips-tricks-.html なので、keynameにprefixつけて運用するような設計にしておくとよきに計らってくれるみたい。(もちろんつけ方は気をつけないといけない) もちろんこれは、高負荷の時に考えるもので下記のリクエストレートが常時超えてるような場合に有効. PUT/LIST/DELETE が 100回/sec GET 300回/sec 急激な増加で下記を超える場合がありそうならサポートに連絡的なことがかいてある。 PUT/LIST/DELETE が 300回/sec GET 800回/sec でも、GETリクエストを抑えるだけなら、CloudFrontにキャッシュさせて配信させるほうが安心かも。 自分のブログはAWSに移行してから、S3 + CloudFrontで配信してる。 特にS3に大量アクセスが来るわけではないのでS3だけ使ってても良かったのだけれど…. https://www.slideshare.net/hz_ouchi/20130222-16684434 備忘録として残しておく。 そういや1年前に買った書籍 AWS クラウドデザインパターン設計ガイド 実は1年前に買って全然読んでなかったのを思い出して昨日読んでました(笑) デザインパターンはある程度知ってたけど、 実際に手を動かして環境を作って動かしてみたのは少ないので、気になるところだけでも作ってみようと思う。 さすがに75パターンあると全部試すのは結構しんどいから気になるところだけ。 AWSは進化が激しく古くなったパターンもあるようで、そこは公式読みながら補完したほうがよさそう。 Cloud Design Pattern »

Github PullRequestのOpen/CloseのみをSlackに通知する

ChatOps系で使い古されたネタです。 Slackには元々Github Integrationがあるんですが、 無料で利用してると1チームで使用できるIntegrationには限りがあるのと Integrationを別で流用したかったので、その練習もかねて PullRequestのOpen CloseのみをSlackに通知したくて、ServerlessFrameworkでコードを組みました。 アーキテクチャ GithubからAPIGatewayのendpointに対してメッセージを投げて、 LambdaでメッセージをparseしてSlackにメッセージを投下するという感じです。 実際に作ったもの github-pr-notification/328 - github 実際にこんな感じで使えます。 作る上で困ったこと GithubからLambdaにpayloadを持ってくる時にpayload={ "message" : "test messages"}とJSONっぽいただの文字列が降ってくるんですが、ここをどうするかで少し悩んでました。結局、slice(8)で最初の文字列をそぎ落としてJSON.parseしました。 とりあえず、sliceするか正規表現でマッチかけてごにょごにょするかしか今のところは思いつかないですが、他に良い方法があったら誰か教えてくださいm(_ _)m おわりに APIGatewayやLambdaを結構使ってきましたが、そろそろDynamoDBとの連携もやってみたいなと思ったり。 CodeBuildで遊んだりもしてるのでそろそろ記事を投下しようと思います。 おしまい。 »

Lineトークにアップした画像をS3に保存する

先日はRekognitionを利用して飯テロ禁止botを作成しましたが、 今回はLINEにアップした画像をS3に保存するbotを作ってみました。 Lineトークにアップされた画像は2週間でLineサーバから削除されるため、 後でダウンロードしようと思った時に有効期限が切れてしまってもう1度アップし直してもらう… なんてことがありました。 アルバムに置いてれば保存期間は無期限なんですが やはりトーク内に画像貼り付ける方が楽ですからね。 そんなこんなで、S3に置いて永続化できるといいなぁと思った次第です。 アーキテクチャ 基本構成は前回のものと同じですが、RekognitionがS3に置き換わっています。 実際に作ってみた コードはGithubに置いてます。 https://github.com/328/serverless-practice/tree/master/linebot-s3 serverless.yml LambdaにはS3の書き込み権限を付与します。(めんどくさいのでフルアクセスにしてるのは申し訳ない) 環境変数はLine developerからとってくる handler.js 保存するファイル名をどうしようかなぁちょっとばかり悩んでたんですが 「画像をMD5関数に突っ込んでハッシュ値を得る。そのハッシュ値をファイル名として利用する。」 としました。 メリットとして 同じ画像が既に上がっていた場合は上書き保存される。 同じ画像はリストに出てこなくなるので一種の重複排除機能として利用できる。 もちろん問題点はあって 「ハッシュ値は衝突する可能性がある」 ということで この辺りを改善するには ハッシュ値 + タイムスタンプ でファイル名とする 既に同じファイル名のものがS3上にあるか検索し、あればMD5とは別のもので再計算する くらいでしょうか。 実際に大量のファイルを保存する場合にはこの辺りも考慮にいれないといけなかったり。 あとは他のアルゴリズムを使うと計算量が多くなる可能性があったり その分Lambdaの実行時間が長くなってしまう可能性もある(要検証)。 個人で利用する分にはこれくらいのもので良いし、 違う画像でMD5が一致した場合には画像が消えてしまいますが、 その辺は許容します。 という感じでLinebotを作ってみました。 先日のRekognitionと組み合わせれば画像を仕分けしつつ保存できそうですね。 もう少し時間を作って他のLINE APIも触ってみようかなと思います。 »

飯テロ禁止botをLINE + AWS Rekognitionで実装する

先週、JAWS-UG沖縄 画像認識サービスを使ってみようハンズオン / もくもく勉強会 2017年7月に参加してきました。 AWSの画像認識サービス(Rekognition)を使って感情ランキングアプリを作るハンズオンをやっておりました。 JAWS-UG青森で開催されたハンズオンの再演で、感情ランキングアプリを作りました。 Rekognition使って何か作れないかなあと考えてたら そういやパリピ共がよくご飯の時間に美味そうなご飯の写真をうpしてくるので それを撃退できるbotが作れたらいいなと思ってちょっと頑張ってみました。 ちょっとググってみたら似たようなことを既に実施してる人がいたのでこれを元にちょいっと変更したらできそうな感じ Amazon Rekognition × LINE Botを試してみた - Qiita 実際に作ったもの 下記の画像を見てもらえればわかる通りご飯画像を投げるとアラートメッセージが飛んできます。 アーキテクチャ Line DeveloperのサイトにWEBHOOK_URLを登録する項目があるので、そこにAPIGatewayのURLを登録する。 Linebotへの個別, もしくはLinebotが属するグループに対して発言なり画像を送信するとアップロードするとWebhook URLにイベントが通知されてAPIGatewayを経由して、Lambdaが処理を行う。 そのイベントが画像であればLambdaを介してRekognitionで解析をかける。 それがご飯であればアラートを上げるようにします。 Rekognition自体は日本のリージョンで展開されてないサービスですので、バージニア北部等のリージョンで利用します。 APIGateway, Lambdaもそれに合わせて今回はバージニア北部のリージョンで利用します。 Rekognition Rekognitionに画像を投げると下記のような感じでラベル付けをしてくれます。 { "Labels": [ { "Name": "Bowl", "Confidence": 97.36100769042969 }, { "Name": "Dish", "Confidence": 69.66221618652344 }, { "Name": "Food", "Confidence": 69.66221618652344 } ] } 今回のお題は「ご飯の画像であればアラートを上げる」ですので、 LabelsのNameのValueがFoodでConfidenceのvalueがある一定以上であればメッセージを出力できればOKです。 Line -> APIGateway 一部マスク・省略してますが、LINEからAPIGatewayに入ってくるパラメータはこんな感じです. { resource: '/', path: '/', httpMethod: 'POST', headers: { Accept: '*/*', 'Content-Type': 'application/json;charset=UTF-8', Host: '********. »

Zabbix-Agentを起動してもプロンプトが返ってこなかった話

AWSでインスタンスを立ち上げてZabbix-Agentを入れたものの, systemctl start zabbix-agent と入力するとプロンプトが返ってこない. DebugLevel上げてみてログを見たりするものさっぱりわからず. とりあえず /usr/lib/systemd/system/zabbix-agent.service を開けてみて PIDFileがどこに吐き出されるかチェックしてみる. PIDFile=/run/zabbix/zabbix_agentd.pid どうやら /run/zabbix に吐き出されるらしい. しかしディレクトリを掘ってみてもNo such file or directoryと怒られる. そういや /var/runって /runとlinkされてなかったっけかとふと思い出して 調べて見たらLinkされてなかった… そして、/var/run/zabbix/が見つかった. あー、PidFileを/run/zabbix/に書き込もうとして, ディレクトリがそもそもないからプロンプト返ってこないのかあと考え zabbix-agent.serviceを下記のように書き換えて PIDFile=/var/run/zabbix/zabbix_agentd.pid $systemctl daemon-reload $systemctl start zabbix-agent よし、これで動いた。 »