あすたぴのブログ

astap(あすたぴ)のブログ

Meltdown,Spectreの対応

をした。AWSです。

やったこと、方法をまとめておく。

前提条件

対応方法

AWSの対応

https://aws.amazon.com/jp/blogs/news/processor_speculative_execution_research_disclosure/

新しいAMIを起動する or sudo yum update kernel を実行すると対応が出来る。

対応方法

launch configのAMIを変更できないため、作り直しになる。 autoscaling groupに紐付けていると、作り直すことが出来ないため、一旦他のlaunch configに付け替えることになる。

A config を最初に紐付けていた場合、この設定を元にB configを作成し、このときAMIの設定を更新する。

具体的には今回は以下のように更新した。

使用していたAMI

- ECSクラスターインスタンス
  - amzn-ami-2016.09.g-amazon-ecs-optimized (ami-f63f6f91)
- EC2インスタンス
  - amzn-ami-hvm-2017.09.1.20171103-x86_64-gp2 (ami-2803ac4e)

最新のAMI

- ECSクラスターインスタンス
  - amzn-ami-2017.09.f-amazon-ecs-optimized(ami-72f36a14)
- EC2インスタンス
  - amzn-ami-hvm-2017.09.1.20180108-x86_64-gp2(ami-33c25b55)

autoscaling groupに設定しているlaunch configをB configに付け替える。 この状態で、最小台数を増やすことで新しいAMIでインスタンスが起動する。 このとき、AZで均等になるようにインスタンス数は倍にする。(AZにそれぞれ1台ずつの2台だったら4台にする)

以降はECSクラスタインスタンスとEC2でやり方が分かれる。

ECSクラスタインスタンス

新しいインスタンスクラスターに増えたことを確認したら、クラスターのインスタンスリストから古いインスタンスを選択し、dorainingをする。 drainingをすると、このインスタンスは廃棄予定ということがECSのagentに伝えられタスクを別のクラスターに安全に移してくれる。 一気にやってもいいと思うが一気にやった場合に、一時的にサービス数が倍になるためメモリが足りなくなりタスクを配置できなくなる可能性があるため、そこを気にしつつ行う。 すべての入れ替え予定のインスタンスをdrainingしてタスクがなくなったら、autoscaling groupに設定したインスタンス台数を元に戻す。 このとき、インスタンスの削除ポリシーがdefault or OldestInstanceになっていないと新しいインスタンスが削除されるかもしれないので確認しておく。 削除ポリシーは変更可能なので、このときだけ変えてもOK。

EC2インスタンス

インスタンスが起動したら、そのインスタンスが正常に機能しているかを確認する。 起動しただけでは機能していないなら、機能するように何かする。 既存のインスタンスと同じように稼働していることが確認できたら、autoscaling groupのインスタンス台数を元に戻す。

正常の機能しているかどうかは、ELB,ALB,NLBに紐付いているインスタンスがヘルシーになっており、サービス(Webアプリ)にアクセスできるかを見ればよいと思う。 確認方法は各サービスなり、動いているものによって変わるのでいい感じに見る。

ECSクラスタインスタンス同様に削除ポリシーは気にしておく。

まとめ

インスタンス起動時に、設定がすべて完了していて起動後のサービスへの入りも自動化されていれば簡単にインスタンスを入れ替えられる。 AMIも最新にして、ECSの場合はagent,Dockerのversionも最新に出来たのでちょうどよかった。

AWSが用意しているAMIに色々設定を入れて、イメージを保存してそれをlaunch configに指定しているとちょっと面倒だな。という感じ。

1台1台再起動、もしくはいくつかずつ再起動みたいなのは辛いのであまり選択したくない。

2017年の振り返りと2018年の話し

2018年になりました。本当は2107年中に書いておいたほうがいいことですが、年末がバタバタしていたような気がするのでこのタイミングになりました。

2017年にやっていたこと

ブログを見てみると18記事書いてました。それらを振り返ってみると、terraformの基礎やDockerでのRailsの環境構築、CirlceCi2.0、WardenやDeviseの認証周り、webpack、ECSについてな感じでした。 これが何をやっていたかと言うと、新しいプロジェクトの開発と参加が決まって、そこで使う技術の選定や調べごと、やった結果を残していた感じです。結果的には調べた内容は全部使いました。

構成としては、サーバーサイドにRubyRails、フロントにReact、Vue、AWSアーキテクチャとしてはECSでDockerを使用しています。 他には新しめの機能では最近NLBを導入しました。ぼくが直接やったわけではありませんが、NLBの背後にnginxを置き、そこでSNIで使用する証明書を動的に切り替えて、バックエンドはECSのRailsコンテナに流しています。面倒なポイントとしてはECSのデプロイが走ったタイミングでNLB背後のnginxのupstreamを更新することですね。(ぼくが作ったわけじゃないですけど。)

webpackを使用していると書きましたが、Rails5ではwebpackerが追加されてwebpackが使いやすく?なりましたが、あまり依存したくないので、Railsの仕組みとは分離してwebpackを使っています。

今年やった一番大きいこととしてはSSL証明書の動的発行(取得)ですね。これは先程書いたNLB背後のnginxで証明書の動的切り替えの話しとの関連です。 ブログでACMEプロトコルについて触れていますが、Let'sEncryptを使用してサービス利用書が使用するドメインの証明書を動的に取得、配置しhttps化をしています。 詳細はまたブログで書きたいと思っていますが、Railsとバッチの連携をSQSで行っていて、証明書を取得するための作業を分割し、キューを受け取ってバッチが処理するって感じで行っています。 Let'sEncryptのクライアントは公式やOSSでいくつかあるのですが、ACMEプロトコルを理解したかったという所と、細かい制御を自分で行いたかったのでクライアントを自作しました。一番しんどかったのは現行のLet'sEncryptのサーバーがいつ時点のRFCを実装しているのかがわからなくて、いろんなバージョンのRFCを読んだり、自分でデバッグしたり、他OSSのコードを読んだりしたことですね。 暗号化周りの知識も不足していて、それは暗号技術入門で補いました。 大変でしたけど、結果的にはうまくいって楽しかったです。

あと、ECSのデプロイはECSを導入している会社でも色々やり方に違いがあって、どうするか悩んだ結果これも自作しちゃいました。githubに公開されてますが、別に紹介するほどのものじゃないので記載はしません。なぜか、Rubygolangで2種類作っているのですがSDKの仕様が結構違うのがだるくもあり面白くもありました。APIの設計としてこっちはこの方が便利だなぁとか、なんでこっちにはこれが戻り値にねーんだよ。とか。 devとprodで使い分けていますが、devはCirleCIで最後に自動でデプロイしています。prodはslackから指示することで任意のタイミングでデプロイ出来るようにしています。 デプロイのツール自体は非常に単純にしていて指定したサービスのタスクを更新してリビジョンをあげてサービスを更新する。だけです。 ECSのデプロイは環境変数の追加、削除や、タスク、サービスの作成をどこでやるかという問題がそれぞれのツールによって解決策が違うのですが、自分の場合は一番最初のタスク、サービス作成は手動でそれ以降単純デプロイはツール任せ、環境変数の追加はそのときに自分で追加。です。 なぜかというと現在の規模ではサービスの追加はほぼない。環境変数の追加もあまりない。ということで単純デプロイがほとんどの状況でツールを必要以上に複雑化したくなかったからです。OSSのツールはほとんどが多くの機能を持っているので、それらを把握し自分の用途を調べるだけでも大変です。なので自分が必要な機能だけをサクっと作ったほうが楽で勉強にもなりますね。

いまさらですが、このプロジェクトでのぼくの役割はなんとなく開発をリードするって感じでしょうか。明確に役割を言い渡されたわけではなく、最初はサーバーインフラがぼくでフロント、デザイナーが1人ずつって感じだったので自分の領分すべてをやる予定だっただけですけど。 開発環境を用意して、アーキテクチャや技術の選定をして、開発の基盤?みたいなの作って、CI環境整備してインフラ作ってデプロイツールを作った。全てまっさらな状態からのプロジェクト開発は人生で2回目で、なかなかない機会なので1回目から約2年くらい空いた状態で今の自分ならどこまで出来るかっていう感じでやりました。いろんなものを整備したのはよかったですが、細かい部分(コード設計)まで回らなかったところと自分でも答えのない状況だったりして、こうしてればよかったなという所がいくつかありました。そのへんはまた次の機会に活かせればなと思います。

その他、2017年の出来事とか

  • 2017年11月で転職してから2年が経ちました。
  • 結婚が決まりました。
  • 転職しようとして内定承諾もしていましたが、事情により内定辞退、辞職キャンセルとなりました。(相談に乗ってくれた方ありがとうございました。ご迷惑をおかけした方申し訳ございませんでした。)

2018年の話しとか

どうしようかなって感じです。直近で気になっているのはイーサリアム上で動作するアプリの開発です。いろんな会社を見て回りたいと思っているので、もし面白そうな話しがあればお声がけしていただければと思います。

2017年買ってよかったもの

雑に書いた。特に順番つけてないです。

Nintendo Switch Joy-Con (L) / (R) グレー

Nintendo Switch Joy-Con (L) / (R) グレー

Nintendo Switch Joy-Con (L) / (R) グレー

発売日に買えて本当によかった。品薄になることはわかりきっていたので絶対にsplatoon2発売までには入手しておく必要がありましたね。あと品薄といいつつ、毎日のようにネットのどこかでは入荷していたので情報をキャッチアップして仕事中でもすぐに買えるような人なら割りとかんたんに手に入ったと思います。友人のために探したときも、探し始めた日には買えました。

Splatoon2

発売日に買ってからずっとプレイしてます。毎週のようにアップデートして武器やマップが追加されるし、定期的にバランス調整で武器の強さが変わるのでその時々で対戦内容も変わってずっと楽しめています。

三菱重工 roomist スチームファン蒸発式加湿器 ブラック SHE35ND-K

1月に買ってた加湿器。2年目の冬ですが現役で活躍しています。会社でよくもくもくしてる加湿器はすぐ臭くなって悲しい感じなんですが、これは臭くならなくてよいです。

フィリップス 電動歯ブラシ(ブラック)PHILIPS sonicare ソニッケアー ダイヤモンドクリーン HX9352/55

自分で磨くよりも圧倒的に磨けてるので楽です。

暗号技術入門 第3版 秘密の国のアリス

暗号技術入門 第3版

暗号技術入門 第3版

昨今話題のビットコインの使用されているブロックチェーンの肝となっているのは暗号技術ですね。 これを読むとブロックチェーンが何故安全なのか。ビットコインの採掘が何をやっているのか。というのがわかっておもしろいです。

ティファール フライパン 鍋 9点 セット ガス火専用 「 インジニオ・ネオ グランブルー・プレミア セット9 」 チタン プレミア 5層コーティング L61491 取っ手のとれる T-fal 【IH非対応】

料理をするのに買いました。鍋やフライパンの取手っていらないですよね。洗いにくいし、シンクに置きにくいし、しまいにくい。それらをすべて解決した画期的な取れる取手。

AirPods

ブルートゥースイヤホンはいくつか試したのですが、どれも充電のわずらわしさ、持ち時間、耐久度的にだめすぎました。2500円でそこそこよいイヤホンがあったのですが、うまく使うためには2個買って、1個を使ってる間にもう1個を充電するという使い方をしていました。 AirPodsは完全にコードレスで、ケースに入れておくと充電される。そして耳につけた瞬間にiPhoneと繋がって、(設定によって)タップすると音楽が再生される。 最高ですね。持ちもよいし、そもそも長く音楽聞くときはコードのあるイヤホン使います。

Kindle Paperwhite Wi-Fi 、ブラック、キャンペーン情報つき

kindleは3個目なんですけど、本を読もうって気になったら新しいの買っちゃう。 1個飛ばしくらいで新しいkindle買ってると結構進化してて感動するのでおすすめです。 iPadもありますが、ビジネス書や小説を読むなら読みやすさとしては断然kindleです。 漫画はiPadで読みましょう。

ちなみに kindleには種類があって、キャンペーン情報付きかどうかがあります。(前はdocomoの3Gがついてたんだけどいまはないみたい?) キャンペーンというのは広告のことでTOPやスリープ画面に広告が入ります。これがうざってぇって人はキャンペーンなしにするといいです。ちょっと高くなります。 最初はキャンペーンなしを使っていたのですが、どうでもよさそうと思ってキャンペーン付きにしましたが、どうでもよかったのでこちらでよいです。

暗号技術入門を読んだ

暗号化周りの知識が全くなくて、SSL/TLSやその他、周辺技術をを扱うにあたって非常に困った。言語ごとにライブラリがあるにはあるが、詳細はOpenSSLのドキュメントを読んだください。とか書いてあったりして、そもそもの知識がなければ何をどうすればいいかはわからなすぎた。実際、知らない人が使うものではないのだと思う。 というわけで、早急に知識が必要。だけど数学的なことはわからない。そこでこの本を読むことにした。

暗号技術入門 第3版

暗号技術入門 第3版

本書は数学的なことを控えめにし、暗号技術の概要をうまく説明してくれる本になっていた。ざっくりいうと以下の感じ

まぁ目次とほぼ同じなんだけど、単語を見ると大体聞いたことがあるのではないかと思う。何かしらのプログラムを書くときになんとなく使ってきたのではないだろうか。最後にSSL/TLSがでてくるがこの技術はそこまで説明した暗号技術をすべてといっていいほど使用している。その為、最初からしっかりと読み進めることで理解ができるようになっている。

これを読むまでは公開鍵暗号を至るところで自分で使用しておいて、その中身として何をしているかを理解していなかった。詳細な数学のことは読んでもわからないが、なぜこのアルゴリズムが解読困難なのか、なぜ公開鍵、秘密鍵に別れているのか、なぜ、秘密鍵で暗号化したものを公開鍵で復号化できるのか。がわかるようになる。 あとは乱数とか。乱数にも種類があり、弱い擬似乱数、強い疑似乱数、真の乱数という3つに本書では分類している。昔、公開鍵のペアをWindowsのアプリで作るときにマウスをぐりぐりしていたことがある。それが何をしていたのかがわかった。真の乱数というのは再現不可能であることが必要でマウスのぐりぐりなどは再現ができない。それを乱数の元にしていたということだった。

この本は今後SSL/TLS化が必須になってくる時代でエンジニアとして生きるのであれば一度は読んでおいてもいいのではないかと思った。またSSL/TLSプロトコルについて詳細に知りたい場合はReal World HTTPも併せて読むといい。

暗号技術入門 第3版

暗号技術入門 第3版

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術