Reach Over The Sky, Tear The Sky

ブログ執筆のリハビリにもなるので閑話休題的な話題について備忘録を残そうと思います。 私はここ最近Nintendo Switchで出た「 大乱闘スマッシュブラザーズSPECIAL 」（スマブラSP）にハマっており、わりとオフタイムの時間をそれに捧げています。 スマブラSPではいくつかのオンライン対戦機能があり、それらをより快適にプレイするために、現状の確認と課題の洗い出しを行なったりしてみました。 オンライン対戦機能の種類 「だれかと」対戦 任天堂のサーバでマッチングが行われ知らないだれかと対戦する レーティング機能があり強い人のレートは高くなる 「専用部屋」対戦 いわゆるロビーを作成しフレンドを呼んで好き勝手に対戦する ロビーには最大8人まで参加でき対戦していないときは他のフレンドの対戦を観戦できる 結論 NTT東日本フレッツ光＆インターリンクの場合ネットワーク内のMTUを1454にしないと接続状況が著しく不安定になりニコニコ動画をはじめ一部のサイトはそもそも閲覧できなくなる IPv6接続には「IPoE（ネイティブ）」と「PPPoE」の2種類があり本命は「IPoE」 インターリンクはどちらのIPv6接続方式も提供しているが「IPoE」の場合はオプションサービスとなっている 「PPPoE」接続でIPv6環境を実現しようとする場合はその仕様上ルータをYAMAHA RTX等のエンタープライズ利用に耐えうる機種に置き換える必要がある インターリンクの「PPPoE」版IPv6接続は無料で利用可能だが仕様上ルータの買い替えが必要となった UPnPはセキュリティの課題があるプロトコルであるし家庭ではまず使わないので無効にする HWでのNATは無効化したほうがいいらしい…確かに家庭用ルータはHWスペックが低そうだからオフロードさせない方がいいのかも（程度は不明だが速度は上がった） WAN側からのPingは応答するようにした方がいいらしい…固定IPを引いている訳では無いので許可してみた（程度は不明だが速度は上がった） ほんとかどうかわかんないけどSwitchの有線接続の場合Cat7よりCat6の方が逆に性能が出るらしい… 逆にノイズが乗るらしい …なるほど 現状 有線接続で混雑時間帯でも60Mbps程度は出力されているの...

表題の通り AWS Summit Tokyo 2019 の Day3 だけ行ってきました。 3日間行きたかったけど都合つかず…。 企業ブースには寄らず、講演拝聴スケジュールを詰め込んで、合間にAWS認定資格の保有者しか入れない「認定者ラウンジ」に入ったりした程度で、かなりミニマム（かつギッシリ）な感じの1日でした。 こんな感じの拝聴予定でした。リンクはそれぞれの発表資料 or 他者さまのまとめとなっているのでいい感じに飛んでいただけると思います。(ほとんどクラスメソッドさんのまとめですが公式資料が出たらそっちに切り替えます) ------------------------------------ 6月14日 10:00-11:30 　 基調講演 ------------------------------------ 6月14日 12:00-12:40 　 メルカリ写真検索における Amazon EKS の活用事例 ------------------------------------ 6月14日 13:00-13:40 　【仮】来たるべきAI時代のための「イケてる」データ基盤の作り方 ------------------------------------ 6月14日 14:00-14:40 　 Deep Dive DynamoDB ------------------------------------ 6月14日 15:00-15:40 　 ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker運用の知見 ------------------------------------ 6月14日 16:00-16:40 　 めざせ！サーバレスプロフェッショナル ------------------------------------ 6月14日 17:00-17:40 AWS   & Alexa Automotive : Worldwide Automotive industry trends ------------------------------------ 13:00 - 13:40 のだけ会場がわからず（なんか地図持ってなかった）の...

自分のためのメモの意味合いが強いです。 時系列で書いてみます。 それまでの自分 AWS歴は4年ほど EC2とかELBとかRDSとかのいまどきの「サーバーレス」っぽくない基本のプロダクトを業務でよく使っている 最近はWAFとかSAMとかいじってる ACMがDNS認証可能になってRoute53に勝手にレコード書いてタダでソッコーSSL証明書が入手できるのはほんといい時代だなーといつも思っている アプリのコードは書いていない 運用自動化のコードはマイペースに書いている 今の会社に転職する前に当時のAWS本を何冊か読み漁りあとは Developers.io や Qiita や公式ドキュメントで自分なりに学習してそれを業務で試す日々 Developers.io はメッチャお世話になっておりますクラスメソッドのみなさん本当にありがとうございます 40日前 受験を決意 公式の模擬テストを受けたんだけど ソリューションアーキテクト アソシエイトを合格したご褒美として無料 だった さらに 本番の試験費用もご褒美として半額になるクーポンが利用可能だった 模擬テストは全部画面キャプチャして見返せるようにした 模擬テストは受けた直後に結果がメールで届く 模擬テストの総合スコアは75%だったので頑張れば受かるぞという気持ちになった 39日前〜10日前 平日はふつーに仕事してた 仕事が結構大変で全然勉強できてなかった 休日は疲れを癒すのでわりと精いっぱいだったので全然勉強できなかった 7日目〜前日 GWに入ったので勉強のチャンスだった GW前までは仕事して気分転換にお酒飲んでゲームして寝るような日々が多かったのでなかなかスイッチを切り替えられなかった 毎日1時間ずつ増やしていった。1日目1時間、2日目2時間、3日目3時間みたいな…。 模擬テストのキャプチャを見返してSQSの知識が足りてなかったからSQSの公式ドキュメントを順番にたくさん読んだ 2日前からSQS以外のサービスについて「軽くは知ってるよ」レベルになるように学習対象をリストアップしてそれらについて各種ドキュメントを読んだ Code*系のサービスをもっと学習しておけばよかったなと思ったけど間に合わなかった Nintendo SwitchのFi...

自分のためのメモの意味合いが強いです。 時系列で書いてみます。 それまでの自分 AWS歴は3年半ほど EC2とかELBとかRDSとかのいまどきの「サーバーレス」っぽくない基本のプロダクトを業務でよく使っている ACMがDNS認証可能になってRoute53に勝手にレコード書いてタダでソッコーSSL証明書が入手できるのはほんといい時代だなーといつも思っている アプリのコードは書いていない 運用自動化のコードはマイペースに書いている 今の会社に転職する前に当時のAWS本を何冊か読み漁りあとは公式ドキュメントで自分なりに学習してそれを業務で試す日々 40日前 受験を決意 二千円払って公式の模擬テストを受ける 模擬テストは全部画面キャプチャして見返せるようにした 模擬テストは受けた直後に結果がメールで届く 模擬テストの総合スコアは84%だったので安心する 39日前〜10日前 平日はふつーに仕事してた 帰宅後スイッチ切り替えのため30分だけスマブラしたりしてた お酒飲みながらいつもより多めにAWS公式ドキュメントを読んだりした 週末に読みたい記事をTodoistにToDoとしてメモした TodoistはURLを貼ると記事名に変換されそれがタスクになるので便利 画面キャプチャの問題文を読み直しよくわかっていないプロダクトや単語をピックアップして自分の重点学習項目とした 多分1日30分 ワイヤレスイヤホンを買ったので皿洗いをしながらEFSのBlackbeltの動画を流して聞いたりした…2周したけどおかげで知識ゼロからだいぶ増えた 試験は平日にしか受けられなかったので会社に「AWSの試験受けてくるので休みます！」宣言をして許可と応援をもらった 10日目〜前日 週末の日中帯は部屋でずっとドキュメント読んでた Redshiftを業務で使ったことがなかったのでクラスメソッドさんのRedshiftの記事から新しい順に10本読んだりしてその記事に貼られている公式ドキュメントも読んだりした 1週間前から禁酒を開始して最後まで飲まなかった 英語オンリーっぽいけどAWSの公式ラーニングサイトで勉強動画見放題なのに気づいてすげーってなった 当日 テストセンターでの受験 米国（ホントかわかんない...

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に...

結論 結論から言うと API Gateway でした。 ACMで発行したSSL/TLS 証明書を シームレスに他のAWSプロダクトで利用することが可能なのですが、その時に内部動作としては規定のアカウントIDでCloudFrontディストリビューションが生成され、そのディストリビューションに対して証明書が適用されるようです。 直面した問題 AWSでのシステム運用にあたり、それなりの数のドメインを運用しているのですが、基本的にはACMにて発行した証明書を利用しています。 以前はメール認証しかできず、きちんと環境を整えてあげないと自動更新に失敗することもあり、DNS認証の同一ドメインの証明書を別に発行し、そちらに切り替える作業を行なっていました。 ACMで発行した証明書はAWSコンソール上から簡単にELBやCloudFrontといったAWSプロダクトに利用することが可能なのですが、証明書を削除する際には全てのインスタンス・ディストリビューションから利用を解除する必要があります。 「あとはどの子（インスタンス）が使っているのかな〜？」と確認したところ、 arn:aws:cloudfront::969236854626:distribution/ABCDEFGHIJKLMN のようなCloudFrontディストリビューションが利用していることがわかりました。 969236854626 の部分が自分のAWSアカウントIDになりますが、私が利用しているアカウントのIDは全然違います。 対策 「えっ…？」と思いましたが調べたらすぐに解決。 答えはこちらに書いてありました。 エッジ最適化のカスタムドメイン名を作成する方法 - Amazon API Gateway  https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-edge-optimized-custom-domain-name.html API Gatewayにカスタムドメインを割り当ててHTTPSを利用させたい場合に、AWSは特定のIDでCloudFrontディストリビューションを内部的に自動で作成し、そのディストリビューションに証明書を関連づけるのでした。...

スレッドダンプとは スレッドダンプとは何なのでしょうか。 スレッドのダンプ…JavaのスレッドはJavaを実行する際の実行単位というか、処理の流れの1つのこと。 それのダンプ…ダンプとはあるOSやプログラムのその時の状況を丸ごと取得してファイルなどに出力したもの。 なのでスレッドダンプとはJavaプログラムのある時点での処理状況をダンプとして取得したものになります。 スレッドダンプについては下記などがとても参考になりますのでご参照ください。 (参考) » 「うわっ…私のアプリ、遅すぎ…？」 スレッドダンプでJavaアプリケーションのボトルネックを調査しよう TECHSCORE BLOG http://www.techscore.com/blog/2016/02/05/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E3%83%80%E3%83%B3%E3%83%97%E3%81%A7%E3%83%9C%E3%83%88%E3%83%AB%E3%83%8D%E3%83%83%E3%82%AF%E3%82%92%E8%AA%BF%E6%9F%BB%E3%81%97%E3%82%88%E3%81%86/ あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が http://enk.hatenablog.com/entry/2014/09/22/001303 スレッドダンプツールについて jstackというツールがあり、これを利用してスレッドダンプを取得するのが一般的なようです。 どこの記事を読んでも出てきますし、下記のAdobeの技術記事（2017年10月更新）でも利用されているのでjstackを利用しておけば間違いありません。 (参考) JVM からのスレッドダンプの取得 https://helpx.adobe.com/jp/experience-manager/kb/TakeThreadDump.html インストール方法 普通はJavaを実行しているマシンにはだいたいjstackがインストールされているようなのですが、私が運用しているサーバには入っていなかったので入れてみました。 既存のJDKのインストール状況確認 $ rpm -qa | grep jdk ...