GameWith Engineering Blog

GameWith のエンジニア、デザイナーが技術について日々発信していきます。

AWS Session Manager を Mac の Terminal から利用する #GameWith #TechWith

GameWith Advent Calendar 2018 6 日目担当の @serima です。

最近のマイブームはソードアート・オンライン アリシゼーションです。 SAO シリーズで一番好きなエピソードは「ファントム・バレット」で、気付いたら何度も視聴しています。

Session Manager とは

GameWith ではリモートワーク環境の実現のために AWS Session Manager を利用しています。

AWS Session Manager を利用すると、踏み台サーバが不要になります。 踏み台サーバが不要になるということは、鍵の管理から解放されるということです。

前提として以下を満たしていると、EC2 インスタンスにシェルアクセスが可能になります。

  • シェルアクセスを受け付ける EC2 インスタンスに AWS Systems Manager エージェントがインストールされている
  • EC2 インスタンスの IAM ロールに AWS 管理ポリシー AmazonEC2RoleforSSM が割り当てられている

また、弊社のセキュリティポリシー上 IAM User に MFA 設定(二段階認証)がされていない場合は AWS Session Manager を利用してシェルアクセスができないようになっています。

Session Manager 自体について、詳しくは本家の記事をご覧ください。

このポストでは 「Session Manager の導入が済んでいる状態で、どのように Terminal からシェルアクセスを行うか」についてフォーカスしたいと思います。

aws.amazon.com

Terminal からのシェルアクセス

AWS Console 上から Session Manager を利用する際は当然すでに MFA での認証は済んでいる(Console へのログイン時に確認コードが求められ、それもパスしている)状態なので問題なく利用できます。

しかし、Terminal から aws ssm コマンドを利用して Session Manager に接続しようとすると認証エラーが出てしまいます。(二段階認証ができてないので当然ですね。)

前提

手順

基本的にはこちらの記事(AWS CLI 経由で MFA を使用してアクセスを認証する)を参照していただければ問題ないと思います。

--serial-number には MFA デバイスの ARN を指定、--token-code には二段階認証のコード(6桁の数字)を指定して以下のようにコマンドを叩くと、アクセスキーとトークンが手に入ります。

% aws sts get-session-token --serial-number arn:aws:iam::000000000:mfa/username --token-code 000000 --output json
{
    "Credentials": {
        "SecretAccessKey": "XXXXXXXXXXXXXXXXX",
        "SessionToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
        "Expiration": "2018-10-15T21:39:58Z",
        "AccessKeyId": "XXXXXXXXXXXXX"
    }
}

取得できた SecretAccessKeySessionTokenAccessKeyId をここでは ~/.aws/credentials に以下のように追記しています。 これらのキーやトークンは一時的なもののため、期限が切れたら(デフォルトでは12時間)再設定する必要があります。

[mfa]
output = json
region = ap-northeast-1
aws_access_key_id = XXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXX
aws_session_token = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

その後

% aws ssm start-session --target i-someinstanceid --profile mfa

と、することで Terminal から指定したインスタンスに接続ができます。 ログイン時のユーザは ssm-user ですが sudo で昇格が可能です。(パスワードなし)

ubuntu ユーザになってからは [tab] キーでの補完が効くようになりました。

f:id:serimaryo:20181130231632p:plain

Session Manager で接続中にネットワーク切断した際の挙動

Terminal からの接続テストを行っている際に、ちょっとした実験を行いました。そちらは別記事として投稿してありますので、興味があれば、ぜひご覧ください。

qiita.com

終わりに

Session Manager は割と最近リリースされたものなのですが、インフラエンジニアの方がすかさず検証をして本運用まで導いてくれました。

GameWith では現在のところ AWS を利用していますが、最近は GCP の活用も本格的に始めています。

そのような環境下で、適材適所でクラウドベンダーを選択できるようなインフラエンジニアを募集しています!

www.wantedly.com

参考記事

Mac のプレビューで Slack カスタム絵文字を効率的に作る #GameWith #TechWith

GameWith Advent Calendar 2018 5 日目担当の id:syque です。三度の飯より Slack のカスタム絵文字を作るのが好きです。

弊社エンジニアチームでのコミュニケーションは Slack で行われているのですが、カスタム絵文字も人が増えるにつれ順調に増加し、本日 2018/12/5 時点では 583 emoji が登録されていました。

f:id:syque:20181204124715p:plain
大丈夫? だめだ...ダメです。ダメらしい🤢


何やら危なげな絵文字が登録されていますが、実際のSlack上の利用例を見てもなかなかにカオスです。


f:id:syque:20181204155220p:plain:w300
リンクをシェアするときにさりげなく parrot gif


f:id:syque:20181204155354p:plain:w250
明日から本気出す。


f:id:syque:20181204161258p:plain:w450
ポケモンにはポケモンの絵文字でリアクション。


f:id:syque:20181204155735p:plain:w350
港区。GameWithは港区にあります。なんだこれは。てぇてぇ。


うまくコミュニケーションできてるのかできてないのかよく分からない感もありますが...概ねメッセージに添えたりリアクションに用いたりとで表現の幅を広げるのに活用できているかと思います。

本題

本題です。カスタム絵文字を作成するためには当然素材が必要なわけですが、巷のトレンドもそうですが自社組織・携わる業界ならではのニュースやトレンド、ミームなどがありそこで出回っている事象をカスタム絵文字にしたい! という欲求も出てくるかと思います。

そういった時に加工が必要であればAdobeなど各種画像編集ツールを使って...とやるところですが、エンジニアだと会社のMacにインストールされていないということもままあり得ます。ですがちょっとした切り抜きやサイズ・色味調整であればOS標準機能やMacのプレビューでも問題なく行えたりします。今回はいくつか紹介します。

領域のスクリーンショットを取る

OS標準機能として、⌘ + Shift + 4 で領域を選択してのスクリーンショットが保存できます。デスクトップに保存されます。

f:id:syque:20181204174528p:plain

例としていらすとやさんの塩水ウニの画像を選択して取得してみます。

f:id:syque:20181204174812p:plain:w100

このように取得できます。(もちろんダウンロードできるものはした方が早い)

サイズ変更 & 切り抜き、クロップ

プレビューの機能です。⌘ + Shift + A または 表示 -> マークアップツールバーを表示 でツールバーを表示し、中央付近にあるサイズ変更のボタンをクリックします。

f:id:syque:20181205100322p:plain

サイズ変更のダイアログが表示されるので、任意のサイズに変更します。

f:id:syque:20181205100916p:plain:w250

Slack のカスタム絵文字のサイズは 128x128px と決まっているので、これに合わせてリサイズしたりなどが主な用途になるかと思います。

またサイズ変更するにあたって不要な部分などを切り取りたい場合があるかと思います。 こうした場合に領域を選択して、⌘ + Delete で切り取り、⌘ + K でクロップ(切り抜き)が行えます。(後述のテクニックでも紹介しますが、⌘ + C コピーや ⌘ + X カットもできます) 領域を選択する際に Shift を押しながらドラッグすることで枠の比率を維持することができますので、例えば絵文字向けに正方形に切り抜きたい場合に有効です。(この操作はスクリーンショットの領域切り抜きの際にも利用可能です。) また選択中の枠はドラッグやカーソルキーで動かすこともできますので、境界のピクセルに合わせる際などに有用です。

f:id:syque:20181205104025p:plain:w300

f:id:syque:20181205104322p:plain:w300

綺麗に正方形に切り取ることができました。これを 128x128px にリサイズすれば絵文字に登録できます。

人物などを切り抜き

背景色を自動選択しての切り抜きができます。マークアップツールバーの左から二番目にある色選択ツールのアイコンをクリックします。

f:id:syque:20181205102453p:plain

画像の背景部分をクリックし、任意の方向にドラッグします。これにより色の選択範囲を調整できます。 参考画像だとシンプルな背景色なので分かりにくいですが、木の葉など似た色味を選択してくれるのでうまく範囲選択できれば綺麗に人物などを切り取ることができます。

f:id:syque:20181205102930p:plain:w350

f:id:syque:20181205103357p:plain:w350

このような形に切り取れます。写真とかだと背景が複雑なことも多いので、ある程度切り取って残りは選択ツール(矩形や丸など)で不要な部分やゴミを切り取っていくと良いです。 この例だと輪郭に白い線が残っていたり、スカーフの白い部分まで消えてしまっていたりするので調整が必要です。⌘ + Z でUndoが可能なので切り抜く前の状態に戻し、下の余白を切り取ってから領域選択をもう少し深めに実行してみます。

f:id:syque:20181205105411p:plain:w350

先ほどよりはかなりマシになりました。(あまり変わらない? スカーフは直った...)まだ白い線が残っていたりはしますが、絵文字に使う用途であれば 128px まで縮小されるので、多少のゴミや輪郭は無視してもそれほど見栄えには関わりません。あくまでプレビューを使って気軽に...という範囲なのでこのくらいの気持ちで作ってしまいましょう。

(応用) 複数の画像を重ねる

応用として、複数の画像を重ねるというものをやってみます。 例として、先程切り取った人物の画像にウニの画像を重ねてみます。

二つの画像をそれぞれプレビューで開きます。

f:id:syque:20181205111137p:plain:w350

ウニのプレビュー画面で ⌘ + A で全選択し、⌘ + C でコピーします。その後、人物のプレビューで ⌘ + P でペーストします。

f:id:syque:20181205111359p:plain:w350

ウニの画像がペーストされます。この画像はドラッグで移動、角の丸をドラッグでサイズ変更ができるので配置したい場所まで移動&リサイズします。

f:id:syque:20181205111500p:plain:w350

画像を重ねることができました。透過部分は重ねた時にもきちんと透過するので、前述の切り抜き処理と組み合わせるとかなりクリエイティブの幅が広がります。


登録してみる

せっかく作ったので絵文字に登録してみます。アメデオアヴォガドロがウニを持っているのでそのままの名称で登録します。

f:id:syque:20181205112319p:plain:w350

無事に登録し、Slack で使うことができるようになりました。

f:id:syque:20181205112709p:plain:w350

この発言の後にチャンネルの会話の流れが止まってしまった気がしますが、そんな日もあります。ハイコンテクストな会話を重ねることでチームメンバーのコミュニケーションを高めていくことができるのです。 *1


終わりに

非デザイナーでもMacのプレビューでこのような感じに絵文字が作れます。自分で作った絵文字をメッセージやリアクションに使うと愛着も湧くしコミュニケーションもより活発になること受け合いです。*2

今回紹介した以外にも Mac のプレビューの使い方や絵文字の作成ツール(アニメーションGIFにしたり)などもありますので、皆さまこれを機に良いSlack絵文字ライフを送って頂ければ幸いです。

*1: 言い訳

*2: ハメを外しすぎて業務に支障が出ないようには注意しましょう 👀

HTML5 Conference 2018に参加してきました! #html5j #GameWith #TechWith

GameWith Advent Calendar 2018 4日目担当の GameWithのエンジニアの tiwu です。

先日開催されたHTML5 Conference 2018に参加してきました!

f:id:tiwu_gamewith:20181201155309j:plain
お疲れ様でした!

HTML5 Conferenceに参加するのは3度目で、毎回刺激をもらっています。

今回も見たいセッションがたくさんあったのですが、厳選に厳選を重ね以下のセッションを見ました。

  • 光を超えるためのパフォーマンスチューニング/アーキテクチャ
  • カンファレンススポンサーによるライトニングトーク大会
  • 「それ、AMPで作りませんか?」--- RichでResponsiveかつPWAなAMPの作り方
  • Web Components のリアル
  • Web プラットフォーム再考 ~PWA のもたらす未来の光と影 ~
  • HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで
  • スペシャルセッション

各セッション簡単にですが概要と感想を書いていきたいと思います。

光を超えるためのパフォーマンスチューニング/アーキテクチャ

  • 賽の河原でdivを積む
  • この世界の光の速度はとても遅く、世界中の人とリアルタイムにゲームするにはまだ耐えられない(格ゲーなど致命的
  • 60fpsをwebで目指す= 16msの壁を超える必要がある
  • フロントから見たらサーバーというものはデータをシンクするシステム
  • ローカルキャッシュ > CDN Edgeキャッシュ > サーバーキャッシュ > クエリ叩く
  • しかしキャッシュの設計は難しい
  • 高速化は目的ではなく結果に過ぎない=高速化ができるキレイなアーキの証明
  • コードの綺麗さと速度は両立する
  • つまりみんな綺麗なコードを書こう

SWでHTMLキャッシュをしてサイトを作ったことがあるのですが、あれは本当に光を超える・・・

ただキャッシュ破棄戦略とかが難しい・・・

ここの戦略の難しさは綺麗なコードによる綺麗なアーキが繋がってくるんですね・・・!

資料

カンファレンススポンサーによるライトニングトーク大会

印象に残っているのは新人研修でSlackを作ったLTで、サイバーエージェントさんの新人研修のレベルの高さとそれを超える新卒の技術力を感じました。

ほかチームが機能を沢山開発している中で、開発フローや開発体制などに力をいれ、賞を取ったそうです。

※ビデオチャット?の時に美肌加工する機能などあったらしいです(うろ覚えです

最後に苦労した点を聞かれた際に「他チームが機能を作っている中、開発フローなどに力を入れたため、他チームと比べて遅れている、進捗が悪いなど不安になった」と言っていました。

しかし、メンターに相談して不安を取り除いてもらい自信もって開発を進めることができたそうです。

新人研修の内容、新人、メンター全て合わさって素晴らしい新人研修ができていると実感しました。

「それ、AMPで作りませんか?」--- RichでResponsiveかつPWAなAMPの作り方

  • AMPは3年経って、LP以外にサイト全体をAMPで構築する事例も増えてきた
  • 便利なAMPコンポーネントもたくさんできた
  • AMPは簡単にレスポンシブにでき、一休さんのサイトはとてもいい事例
  • AMPとPWAは相性がいい(文字をひっくり返すとAMP <=> PWAになることからもわかる...w)
  • ただ、URLがGoogleドメインになるのは課題として感じており現在対応中(Signed Exchangeを利用)
  • さらに、AMPでJSが使えるようになる!(WorkerDOMを利用)

ついにAMPでJSが動くそうです(震え声)

サイト全体をAMPで構築し、ほぼ光の速度のサイトを作れるのは夢がありますね!

登壇者によるタイムライン

Web Components のリアル

  • IEを無視すれば今すぐにでもいける(2020年にWin7のサポートが切れるからそこまで待つ説)
  • Custom Elements,Shadow DOM,HTML Template,ES Modulesの組み合わせの技術
  • Custom Elements独自タグを作り、コールバックを定義できる
  • Shadow DOMはDOMをスタイルごと隠す
    • slotで小要素を表示する
  • プロジェクトをまたぐコンポーネントを作る時に便利(ロゴなど)
  • ライブラリに依存しないコンポーネントを作る時に便利(Vue,Reactなど)
  • マイクロフロントエンドの実現
    • コンポーネント内にVueやReactを隠蔽できる
    • ボタンはVueが得意なチームが、カルーセルはReactが得意なチームが作るといった分離ができる
  • Web Componentsは標準の仕様なので使えるなら使ったほうがいい
  • 現実的に作るなら、バニラ,lit-html,lit-element,Vueなどを利用したほうがいい
  • lit-elementが作る時は便利

以前Polymer使ってWebComponentsを作ったことがあるのですが今はlit-elementが主流?ぽいんですね

AMPのコンポーネントもWebComponentsベースらしいです。

今後はJSフレームワークではなく、コンポーネントによるサイト構築が主流になるのかも。

資料

Web プラットフォーム再考 ~PWA のもたらす未来の光と影 ~

  • PWA + ○○ が来ている(Web VRなど)
  • WebなのにPWAのせいで使いづらくなることがある
    • スタンドアローンモードは検索バーが消えるので、検索したい時にブラウザにアプリ切り替えをする必要がある
    • 別のページを開くとき、前のページを上書きして開くので前のページに戻れない
  • PWAで夢を見るな、現実を見ろ

僕も作ったサイトにAdd to homescreen入れたのですが、完全にUXの向上など無視してました・・・。

HTTP の今と未来 ー BBR, HTTP/2, QUIC の基礎から 5G 試験ネットワークでのブラウザベース評価試験まで

  • 5Gが来たが、5Gで何ができるのかが課題になっている
  • この前HTTP/3が出た(HTTP over QUIC)
  • ネットワーク技術の変化を知らないWeb開発者はやばい
  • Softbank X WebDinoJapanが世界初の調査結果を公表
  • Web開発者と共に、5Gネットワークの使い方を創っていきたい
  • 5G IoT Studioという場所を提供している
  • 5GだとHTTP/2のほうが遅い
  • ただまだまだ5Gは調査不足

ネットワーク技術の変化を知らないWeb開発者はやばい

この一文にすべてが込められていました。

資料

スペシャルセッション

LT大会とクイズ大会でした!

1000万以上をAMPにした話

  • WeblioをAMP対応
  • 段階的にAMPにしていった
  • 通常のサイトにAMPコンポーネントを使っている

PureJS

  • Haskellライクな関数型

CSSアンチパターン

  • ビルドプロセスから考えることが必要
  • コンポーネント化されているのにCSSだけグローバルになっていた・・・
  • ビルド後のJSはDRYだがCSSはDRYになってない

Preload,Preconnect

  • とりあえず入れるだけでも負担にならない先読みの仕様
  • APIもフェッチできる

Vivliostyle

  • css組版
  • ブラウザの印刷機能を利用しPDF出力する
  • 利用者が増えてきた

Passive Event

  • Chromeの絵を書く人
  • スクロールにEventを貼ると、スクロールがカクつく
  • heightが変わったりする可能性があるので処理が終わるのを待っているため
  • addEventListenerに{passive: true}を渡すと、処理が終わるまでにスクロールするのでなめらかになる

最後に

以前参加したHTML5 ConferenceはAMPやPWAやWeb Componentsは紹介するセッションが多くありましたが

今回は使ってみてどうだったか、などといった事例のセッションが多かった気がします!

GameWithは、ゲームが大好きで、フロントエンドが大好きな方、新しいWeb技術に興味がある方を大募集中! Wantedly でもよいので是非お気軽にお声がけください!

www.wantedly.com

PHPの現場に「GameWithの現場」というテーマで出演しました #GameWith #TechWith #phpgenba

お久しぶりです。

GameWith Advent Calendar 2018 1 日目担当の @serima です。

去年の今ごろは、GameWith でも Advent Calendar やりたいな…ただエンジニア少なすぎて回すの物理的に無理だ…できない... となっていたのですが、今年はこのような勢いです。

f:id:serimaryo:20181130175941p:plain

エンジニアが増えたこともそうですし、積極的に Advent Calendar を書こうと思ってくれることが、たいへん嬉しいです。

tl;dr

  • PHPの現場という PHP 界隈で有名な Podcast があります
  • 「GameWithの現場」というタイトルで出演させて頂きました
  • みんな聞いてくれよな

php-genba.shin1x1.com

出演までの経緯

PHPの現場のホストである shin1x1 さんのことはかなり前から Twitter でフォローしていました。PHPの現場というPodcastが始まったときに「いつか出たい」なんて言っていたこともありました。

PHP カンファレンス関西 2018

7 月に行われた PHP カンファレンス関西 2018 で GameWith はブースを出展をしていたのですが、なんと shin1x1 さんがふらっと遊びに来てくださいました。 そこで、GameWith のサービス概要やアーキテクチャについて簡単にご紹介させていただきました。実はそのときが初対面でした。

広島での勉強会と台風

そして、9月末に行われた「中国地方DB勉強会 in 広島」というイベントで、shin1x1 さんと僕が登壇者としてそれぞれ Docker と CircleCI について話しました。

Podcast 内でも話してますが、ちょうどそのタイミングで台風 24 号が九州地方に接近しており、イベント後に宿泊すると帰宅できなくなりそうでした。

やむなくイベント終了後はすぐに新幹線に乗って帰ることになったのですが、道中いろいろとお話をしていて、その延長戦として Podcast 収録ということになりました。

ずっと出演したかった Podcast だったので、とても光栄でした。

GameWith を支えるインフラ基盤

Podcast 内で「GameWith Engineer Meetup を行った」と話していますが、その時の資料がこちらです。 Podcast を聴きながら資料を見て頂けるとより理解が深まると思いますので是非ご覧ください。

また、Meetup を行った際にはログミーさんにお越しいただき、記事にしていただきましたのでこちらも合わせてご覧ください。

logmi.jp

収録に利用したマイク

せっかくなので、リーズナブルでそれなりの音質で録音できるというマイクを購入しました。 手元で録音をすると、ささやかにホワイトノイズが乗っていましたが、おそらく編集で簡単に消せるレベルではないかなと感じました。

f:id:serimaryo:20181128135312j:plain
SONY PCV80U ECM-PCV80U

終わりに

GameWith は、ゲームの楽しさをもっと世界に伝えていきたいエンジニアを大募集中です。 Wantedly でもよいので是非お気軽にお声がけください!

www.wantedly.com

GuardDuty(とSecurity Hub)で始めるセキュリティの第一歩 #GameWith #TechWith

初めまして、GameWith のインフラ担当 加我(id:damenaragyouza)です。
GameWith Advent Calendar 2018 の2日目を担当させて頂きます。

ここ最近、外部からの不正なトラフィックによる攻撃が流行しています。
ユーザにサービスを安心して使って頂くために弊社もちゃんとセキュリティを考えていく必要があると感じ、現状の課題と対策を検討しました。

対象となる読者

  • セキュリティ対策を何から始めようか迷ってる方
  • チームにセキュリティの専任がいない状況で開発を行っている方

gamewith.jp におけるセキュリティ上の課題

弊社のゲーム攻略メディアである gamewith.jp は2013年9月にオープンしました。
特定の時間帯でトラフィックが跳ね上がるというサービス上の特性に対し、AWSを活用する事で高トラフィックな環境に対応してきました。

その反面、セキュリティに対しては十分な対策を行えていなかったという事情があり、現時点でどのような課題があるかを調べてみることにしました。

技術的な課題

  • 外部からの不正なトラフィックを検知する仕組みがない
    • ポートスキャンやSSHブルートフォースアタック
    • DDoS攻撃
    • 設定不備によるEC2のインターネット公開状態
  • 内部から外部に対する不正なトラフィックを検知する仕組みがない
    • 外部に向けてのDDoS攻撃やSSHブルートフォースアタック
    • ビットコインのマイニング
  • AWSアカウントに対する不正操作を検知する仕組みがない
    • Credentialの漏洩
    • 各種AWSサービスのAPI不正利用
    • AWS Management Consoleへの不正ログイン

技術的な観点では上記の課題が見えてきました。
これはしっかりと対策をする必要があります。

少し観点を変えてみます。
人的リソースという点でどのような課題があるのかを考えてみました。

組織的な課題

  • インフラの専任は自分のみ
    • そもそもこれまでずっとインフラの専任は不在だった
  • セキュリティの専任はずっと不在である

つまり、インフラとセキュリティに対してガッツリ対策ができる専任のリソースが無かったという状況が続いていました。こういった状況を改善すべく、どのような対策が可能で、より効果的なのかを考えていきます。

理想は「運用に私のリソースをそこまで費やす事なく、いい感じに検知してくれるような都合の良いサービス」です。まぁこんなの無いだろうなぁと思ってたんですがありました。

選ばれたのはAmazon GuardDutyでした

www.slideshare.net

Amazon GuardDutyは AWS環境におけるセキュリティの驚異リスクを検知するAWSマネージドサービス です。
分析する情報として下記の3点が挙げられています。

Amazon GuardDutyの分析ソース

  • VPC Flow Logs
  • AWS CloudTrail Event Logs
  • DNS Logs

上記のソースを機械学習で分析し、脅威(異常)を検知する仕組みとのことです。
Amazon GuardDutyを使用する事で弊社が抱える技術的な課題にアプローチが可能ではと考えました。

VPC Flow Logsからは 外部からの不正なトラフィックを検知内部から外部に対する不正なトラフィックを検知 を、
AWS CloudTrail Event Logsからは AWSアカウントに対する不正操作の検知 を期待します。

導入してみて「やっぱりダメでした」という事もありえるため、30日間のフリートライアルがあるのは個人的に好印象です。

導入

AWS Management ConsoleからAmazon GuardDutyのコンソールに飛び「Get started」をポチるだけです。とても簡単。

f:id:damenaragyouza:20181113155855p:plain
Get started

導入した結果

意図せず外部との通信が可能になっていたSecurity Groupが適用されているEC2インスタンスに対し、外部からポートスキャン(PortProbeUnprotectedPort)が多々行われている事が判明しました。
この結果を踏まえ、Security Groupの全体的な見直しを実施することでGuardDutyが検知した脅威に対する対応ができました。Trusted Advisorを併用するとより効率的です。

f:id:damenaragyouza:20181113170008p:plain
現在はAmazon GuardDutyが検知した脅威をSlackに通知することで運用コストの軽減に成功しています。

[11/29 追記] AWS Security Hubについて

re:Inventで新サービス AWS Security Hub が発表されました!既に東京リージョンでもPreview版が利用可能です。
aws.amazon.com
AWS Security Hubは各セキュリティサービスを一括で管理する事ができるサービスで、文字通りHubとして機能してくれます。
先に導入したAmazon GuardDutyもSecurity Hubから管理する事が可能ですので、今後は全てこちらで管理・操作することになりそうです。

Security Hubの設定ですが、こちらも非常に簡単です。
SecurityHub ConsoleからEnable Security Hubを選択するだけです。
f:id:damenaragyouza:20181129140850p:plain
設定を有効にする際、いくつかのPermissionが必要になるので、内容を確認した上で有効にします。 f:id:damenaragyouza:20181129141149p:plain
StandardsではCIS AWS Foundationsの結果を確認することができます。
設定は簡単で、Enableを選択するだけです。(注意書きを見る限りだと、All resourcesに対してAWS Configを有効にする必要があります)
f:id:damenaragyouza:20181129151926p:plain
Insightsを見ると、様々な観点から問題を報告してくれます。
この観点の中には弊社がこれまで出来ていなかったセキュリティに対する技術的な課題へのアプローチ(Credentialの漏洩やEC2の設定不備/脆弱性)も含まれていました。
GuardDutyと併せて強力にサポートしてくれる事間違いなしです。

f:id:damenaragyouza:20181129142147p:plain
Insightsの一部

コスト

現在トライアルの最中なので最終的なコストはまだ出ていませんがコレくらいです。
この金額は月額のように錯覚しますが日額です。比較的高めではありますが、とても強力かつお手軽なため、トライアル終了後も継続して利用する事にしました。
f:id:damenaragyouza:20181127115730p:plain

終わりに

タイトルに第一歩と書いた通り、Amazon GuardDutyの導入はあくまで「脅威の検知」が目的です。
今後は脅威を未然に防ぐための仕組みづくりや、よりセキュアな運用方法を考えていく必要があります。

このような課題を一緒に考え、一緒に解決していってくれる仲間をGameWithはお待ちしております。

www.wantedly.com

参考資料

Amazon GuardDuty(インテリジェントな脅威検出) | AWS
20180509 AWS Black Belt Online Seminar Amazon GuardDuty
AWS Security Hub | Amazon Web Services (AWS)

GameWithアプリに、iOS12の新機能 Provisional Authorization (お試しプッシュ通知)を導入してみたら通知許諾率が下がった話

どうも皆さんおはこんばんにちは。

スコルパイド3討伐済みのiOSアプリエンジニア @peka3 です。

前回から約3ヶ月ぶりの投稿となります。

先日、GameWithアプリのプッシュ通知許諾率改善施策として、iOS12の新機能 Provisional Authorization(お試しプッシュ) を実装したんですが、 改善されるどころか許諾率が下がってしまいました。

なぜそうなったのか、Provisional Authorization を紹介しつつ原因を深掘りします。

前提

  • GameWithアプリではログインユーザーに向けてプッシュ通知を行っている(当時)
  • 通知許諾率が低い
  • 開封率は悪くないので、通知の質はどうやら問題なさそう

Provisional Authorization とは?

簡単にいうと、ユーザーがお試しでプッシュを受け取れるようになる機能です。

今まではユーザーがアプリの通知許諾ダイアログで「OK」を選択すると、プッシュ通知が受け取れるようになっていたのですが、 Provisional Authorizationでは通知許諾ダイアログを表示することなく、お試しのプッシュを受け取れるようになります。

Apple的には、どんな通知が受け取れるかわからない状態で通知許諾を出されても、ユーザーの混乱を招くということで実装された機能のようです。

参考: 動画の30:00〜

developer.apple.com

これが通知許諾率改善に効果があるのでは!?ということで検証することになりました。

お試しプッシュ通知の制約

通知を受け取っても、

  • 音がならない
  • バッジが表示されない
  • 受信時のアニメーションはない
  • 通知センターを見ることで初めて届いてることが確認できる

という制約があります。

実装方法

すでにプッシュ通知を実装しているアプリであれば簡単に実装できます。

既存の requestAuthorization を実行しているところで option に .provisional を含めるだけです。

var options: UNAuthorizationOptions
if #available(iOS 12.0, *) {
    options =  [.alert, .badge, .sound, .provisional]
} else {
    options =  [.alert, .badge, .sound]
}

UNUserNotificationCenter.current().requestAuthorization(options: options) { granted, error in
   if granted {       
        DispatchQueue.main.async {
            UIApplication.shared.registerForRemoteNotifications()
        }
    }
}

これによって通知許諾ダイアログが出ることなく、デバイストークン が発行されます。

自サーバのDBにデバイストークンを格納してる場合は、レコードが爆増すると思うので注意が必要です。

お試しプッシュ通知受信後

お試しプッシュを受信した状態で通知センターを開くと、以下のような通知が確認できます。

f:id:peka3:20181127120332p:plain:w200

通常のプッシュ通知とは違い、残す(通知をこのまま受け取り続ける)、それともオフにするかのボタンが存在します。

残すを選択した場合は、さらに

f:id:peka3:20181127120622p:plain:w200

  • 目立つように配信してもらうか(ロック画面 通知センター バナー全部出し サウンドとバッジもあり)
  • 目立たないように配信してもらうか(通知センターのみ かつ サウンドとバッジはなし)

をユーザが選択できるようになっています。

これを選択し終えると、ようやくauthorizationStatusauthorized(通知許諾ON状態)となります。

導入後、どういう通知許諾フローにしたのか

当時のGameWithアプリでは、ログインユーザーのみがプッシュ通知を受け取れる仕組みでした(現在は未ログインユーザーもプッシュ通知を受け取れる)。

そのため、アプリ起動時にログイン訴求を表示していました。

f:id:peka3:20181127114759p:plain:w200

それを踏まえて、訴求表示でのボタンを押したときのフローを以下のように変更しました。

  • アプリを初めてDLした人がログイン訴求を見てログインする

    • 今まで: ログイン後に通知許諾ダイアログを出す
    • これから: 今までと同じ
  • アプリを初めてDLした人がログイン訴求を見て「あとで」を選択し、その後どこかのタイミングでログインする

    • 今まで:ログイン後に通知許諾ダイアログを出す
    • これから: ダイアログなしでprovisional にする

このような実装を行ったのですが、

結論としてはプッシュ通知許諾率は向上せず、むしろ下がってしまいました。

なぜ通知許諾率は向上しなかったのか?

前述した制約がやはり大きかったようで、自分から通知センターを見るユーザーが全然いないのではないか?と思われます。

お試しでプッシュ通知を受信できると言っても、気づかれなければ意味がなく、このお試しプッシュ機能はユーザーの邪魔をしないように通知を送るので、結果として通知が届いていてもほとんどの人は気づかずに終わっているようです。。

どうすればもっと通知許諾率が向上していたか?

検証してないので仮説にすぎないのですが、

  • provisionalステータスのまま一定期間が過ぎたユーザーには、通知許諾ダイアログを出す
  • ユーザーがお試しプッシュを受け取って通知センターを見るところまで、アプリ側でチュートリアルとしてサポートする

このあたりまで行えば効果があったかもしれません

闇雲にProvisional Authorizationを実装するだけでは、通知許諾率改善に貢献するのは難しそうです

まとめ

iOS12からの新機能を取り入れてみたのですが、今回のやり方ではうまくできませんでした。

ですが、仮説検証できたという点では大きな収穫でした。

これからもGameWithアプリではこのような仮説検証をどんどん行って、ユーザーの皆様がより満足できるアプリにしていきます!

一緒にやっていっていただける仲間も募集中です!

LINE DEVELOPER DAY 2018 に参加してきました #LINEDevDay #GameWith #TechWith

id:syque です。 2018/11/21 に開催された LINE DEVELOPER DAY 2018 に参加してきました。

linedevday.linecorp.com

f:id:syque:20181121114223j:plain

(ブラウン君割れてた、すまない)

以下の発表を聴講しました:

  • Opening Session - "Next LINE" LINEが創る新たな世界 -
  • LINEが目指す理想の広告プラットフォーム
  • (Lunch Session) パネルディスカッション: グローバルな組織で働くエンジニアから見たLINEのエンジニアカルチャー
  • LINEのインフラプラットフォームはどのように大規模サービスをスケールさせ運用コストの小さなインフラを提供しているのか
  • フロントエンド開発によって進化するLINEの未来
  • (Closing Session) LINEが創る理想のDeveloper Relations

今回はLINEが取り組んでいる技術と、会社やエンジニアチームがどのようにプロダクトに取り組んでいるかということに全体的に触れてみたいという思いからの参加でした。

この先1年で注力していく分野(AI、Blockchain、Fintech)と対応する現行・開発中のプロダクトについて、またそれぞれのプロダクトを取り巻く課題とそれを解決する技術についてが各々のプレゼンで補完的に発表されており、LINEという会社が取り組んでいく事項について大枠から知ることができました。*1

エンジニアが2,100人もいる(3,000人に増やしたいらしい)LINE社と比較すればエンジニアリングで取り組める分野、領域、そして特に規模は大きく異なってしまうとは思います。ですが取り組むべき分野に焦点を絞って組織編成をし、組織を拡大し、新たに表出した課題と向き合って解決策を考えて...といったサイクルを回すという点では一緒であるし、見習うべき点はたくさんあるのではと考えながら聴講していました。

発表内容では以下のようなフレーズ、事柄が印象的でした:

  • LINE Pay の人が会議中に娘から LINE 電話が来て、昼間から何だろう事故か何かか...と思ったら「買い物するので LINE Pay で 5,000 円送って」と。大したことない内容でよかったというのと、電話が終わって会議に戻るまでの間に送金はできてしまって、スマホだけで簡単に送金できる世界が来たなという実感が出たという話
  • 広告プラットフォームの方。広告の配信システムを運用するにあたって「今度こういう広告打つので数万リクエスト増えるけどよろしく」という話が来た時に、インフラどうしようトラフィックは大丈夫かという事項が社内のインフラチームにすぐ相談できる状態だったのはすごく助かった。安心して施策に素早く対応することができていた。
  • アプリは当然のこと、インフラ、フロントエンド、コンテンツデリバリーなど色んなものを独自フレームワークや内部サービス等に内製して運用している
    • (感想: LINE レベルの規模になると既存のサービス・ライブラリでは対応できないので仕方なさそう)
  • LINE の基本理念: Take Ownership, Be Open, Trust and Respect リンク
  • LINE は外国籍のエンジニアが6割
  • 役員がカフェスペースに集まってタウンホールミーティングを行ったりする。厳しめの公開質問が飛んできたりもする
  • 今回の DEVELOPER DAY 含め、ビジョンをエンジニアに伝える施策については CTO が時間を割いて考えている。2,100人というエンジニア全てに接触することはもちろんできないが、全員が自分たちで考えて動けるようになるために共通のビジョンを持つことが必要不可欠なので、それだけ優先すべき事項であると認識して取り組んでいる

LINE 社主催であるゆえの、事業・プロダクトの大きな視点から各々のプロダクトにまつわる細かな技術についてもあり広さも深さもあるカンファレンスだったなという感想でした。 弊社もこのくらい技術発信、プロダクト発信できるといいなと思いました(小並感)。スポンサーシップなどできるところから発信を進めて行きたいです。

最後に

GameWithは、ゲームが大好きで、新しい技術をどんどん使っていきたいという方を大募集中! Wantedly でもよいので是非お気軽にお声がけください!

www.wantedly.com

*1: もちろん内容は発表のためにブラッシュアップされているので、表からは見えない苦労や問題点などもあるのでしょう...