昨日書いた通り、東京遠征2日目はJAWS DAYS 2017（初参加）です。
jawsdays2017.jaws-ug.jp
「できればTwetterかFacebookで #jawsdays #jawsug を付けて」とのことでしたが、あいにく事情によりどちらもアカウント未開設です（消されたわけではないですが）。
いい天気です。
あの3.11から6年、実行委員長の開会挨拶で黙祷をした後、各トラックに分かれてセッションが始まりました。
なお、まだ公開されていないものもありますが、参加したものについては全てのセッションでスライドが公開されるという話を聞いたので、昨日のOSCに続いて、気になったポイントだけ書いていきます。
それぞれの方が1テーマずつデザインパターンについて解説されていました。
※後でスライドが公開されるとのことだったので、それぞれの正確なタイトルはメモしていなくて覚えていません。以降同じ。
まず、山﨑さんから、AWS＋オンプレ（オフィス）のハイブリッド利用の場合のRoute53を使ったデザインパターンの解説です。
20170311 jawsdays 新訳 とあるアーキテクトのクラウドデザインパターン目録（山﨑さん）
可用性・管理性等を考えれば、ハイブリッドの場合メインのDNSはRoute53にしたいですよね。
ただ、AWSとオンプレの回線が切れた場合、大変なことになりそう（AWSではないが本社と地方事務所の間の回線切断で経験あり）と思って聞いていたら、やっぱり「切れるとダメ」とのことでした。
次は、神さんのAMIの維持管理の話。SSHでEC2に接続して個別にメンテしていると、残してあるAMIと使っているEC2のイメージとのかい離が大きくなり、EC2のイメージが壊れたときにAMIから復旧…がすぐにできない、というバッドプラクティスを避けるために、「メンテするなら強制AMI作成」「SSH接続できない（させない）EC2イメージ運用」のパターンを示されていました。
最後は、金平さんのマイクロサービスの話。昨日聞いたことと被る内容が出てきました。
jawsdays 2017 新訳-とある設計士の雲設計定石目録_3（金平さん）
やはりLambdaです、が、まれに処理のリクエストがあっても「発火」しないことがあるそうで（まだ使っていないので経験なし）。
それと、総合テストが大変なので、CloudWatch重要、新サービスX-Rayに期待、とのことでした。
その後、3つほど実際の事例に合わせたデザインパターンが示されました（最後の定期ポーリングについては、Step Functionsを使う／使わないの2つあったので、4パターン？）。
なお、セッション終了後にAトラックを離れる途中、イスの横の床にPowerShell for Azureを置いている人がいて、「やるなあ」と思っていたら…Tweetされた忘れ物の写真の一番上に写っていました。
画面をはみ出しそう勢いなのでスライドは埋め込みませんでした。リンク先で確認してください。
JAWS DAYS 2017 Security-JAWS発表資料 // Speaker Deck
まず、大喜多さんから、基本的なVPCの話がありました。
セキュリティグループとネットワークACLで、フィルタリング機能がステートフルとステートレスの違いがあるから注意してね、とのこと。
また、VPN接続の場合に冗長化を意識したGW設置とルーティングが必要、Direct Connectでの複数VPC接続の扱いの違い（回線事業者のメニューによる）の解説もありました。
次に、吉江さんから、主にDDoS対策の観点からWAFとShield、サードパーティのサービスについての話がありました。
AWSのWAFは現状あまり使えるレベルではありませんが、CloudFrontを使っているならShieldは結構使えそうな感じです。
最後に、森永さんからConfigおよびConfig Rulesの話がありました。
単純な構成管理・変更管理としてだけでなく、リソース間の関係性を把握しながら管理ができるのがいいところ。
ただ、Configで管理できても、正しいかどうかの監査ができないと…ということで、Config Rulesの活用を、とのことでした。
AWSオフィシャルのマネージドルールのほか、個別作成できるカスタムルールもあり、awslabsが30個超のカスタムルールを公開してるよ、ということで、実際に利用するときに探してみようかと思います。
なお、ランチセッションは、管理・監視系サービスの話が聞きたかったのでAトラックに戻りました。
20170311 jawsdays 公開（小島さん）
JAWS-UG生みの親、小島さんのセッションです。
セッションの開始と終了をアナウンスしたスタッフの方が（開始のときも終了のときも）「コジマさん」と紹介されていましたが、某キレ芸芸人のように「オジマだよっ!!」とキレることなくさらりと流されていました（どうでもいいことですが、私も大体名前を間違えて呼ばれます）。
AWSJ卒業後のパラレルキャリアがコミュニティ活動なしには成り立たなかったこと、JOIN先の選び方、実際に始めてみてから生じた問題と解決法などを話されていました。
解決できていないのは名刺の問題（種類多すぎ）とのこと。
私はてっきり「受け取った後の仕分け」の問題かと思ったのですが、どちらかというと渡すときの話でした。
やはり、そのうちスマホを突き合わせてバーチャルな名刺をやり取りするアプリでも作って流行らせて…って、まあ、日本ではパラレルキャリアをする人が少ないので、きっと流行らないでしょうね。
名刺を持たない外国の方とか、中高生を最初のターゲットとしてサービス投入？すれば、もしかすると流行る…？
DevOpsとか言う前にAWSエンジニアに知ってほしいアプリケーションのこと
会社のメンバーのリクエストがあったので、話を聞いてきました。
AWSネイティブのシステムを開発・運用できるのは当たり前（そこをターゲットとしてもエンジニアとしての価値はどんどん下がるだろう）、AWS適性の低いアプリケーションをAWSに持ってくることができてこそ価値がある…というのは、ユーザ側から見ると意外かもしれませんがパートナー側の視点では同意できる人が多いかもしれません（私はユーザ側ですが）。
まずは性能のボトルネックになりやすいRDBMSの話。MySQLのクエリチューニング頑張ってるよ、とのことで、私も同じようなことをしていたのでよくわかります。
「MySQL 5.6以降ではクエリキャッシュOFFが推奨されているけど、アクセスの少ない時間帯のバッチ更新ぐらいであとは参照オンリー、というワークロードなら、クエリキャッシュは使えるよ」という話が出てきましたが、ちょっと補足すると、
・MySQL 5.5ぐらいまでは複数スレッドの並行処理性能が低かった
・MySQL 5.6からは並行処理性能がかなり向上したが、クエリキャッシュはロックの粒度が大きすぎて、更新が度々あるとほぼすべてのスレッドの処理を（ロックが解放されるまで）止めてしまうことになるので、かえって性能が落ちてしまう⇒だから公式リファレンスマニュアルでもOFFを推奨している
・でも、そもそも更新がなければ、ロックで各スレッドの処理が足止めを食らうことがないから、効果はあるよ
ということですね。
因みに、AuroraはクエリキャッシュONがデフォルト／推奨ですが、こちらはロックの粒度や手法に手を入れているものと思われます。
その他、RDBMSからの単純移行のつもりでNoSQLを使おうとすると死ぬとか、CI/CDはアプリケーションが正しく動くことが保証できなかったりアプリケーションのライフサイクルと合わなかったりすると使われなくなるとか、デプロイがたまにコケるとやっぱり使われなくなるとか（それは当たり前）。
また、CloudFrontを使いやすくするために、アプリケーションのリクエストのパターンを整理する（動的リクエストはPOSTに寄せる、GETならパラメータ等のフォーマットを合わせる）と良い、またそれができるようになるためにインフラ族もアプリケーションの理解が必要だよ、という話が続きました。
（長くなったので、その2に続きます。）
