エンジニアのsaekiです。

Keynote1日目で発表された新サービス&アップデートのまとめです。

EC2 instance type

• M5 (General purpose)
• M1 (Big Dataに最適化されたインスタンス)
• 13m (ベアメタル)

Amazon Elastice Container Service for Kubernetes (EKS)

来ると思ってました。満を持して来ましたね。 やっぱりこの発表で一番会場が沸きました。

プレビュー版が本日公開。

AWS Fargate

コンテナ管理を抽象化してくれるサービス。 ECSにぶら下がる各インスタンスやその中で動くDockerを意識することなく、コンテナを管理できるようになるようです。 https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overview/

ECS版は今日からga、EKSは2018年のどこかでサポートされるようです。

Aurora Multi-Master

AWS Auroraのマルチリージョン対応

プレビュー版が本日公開。gaは2018のどこかの予定。

Aurora Serverless

Serverlessのフローに対応したオンデマンドなRDS、という理解です。

エンジニアのsaekiです。 11/27(月)からラスベガスで開催されているAWS re:inventに参加しています。

日本からラスベガスへ

11/26日17:00ごろ成田空港を出発し、約10時間かけてサンディエゴへ。 そこからサウスウェスト航空に乗り換え、1時間後にラスベガスに到着しました。 自分は海外に行った経験が台湾旅行くらいしか無く、10時間のフライトがとても長く感じました。

経由したサンディエゴ空港、ものすごい混んでました

セッション

re:inventの目玉はもちろんKey Noteの新サービス発表ですが、それ以外でも様々なセッションが用意されていたり、AWSを用いたサービス/ソリューションを行う企業様がブースを構えていたりと、Key Note以外でも見所が多いです。

re:inventは"教育的なイベント"と呼ばれています。 参加者のレベルに合わせた1時間程度のセッションが多数用意されており、入門レベルの人から上はエキスパートの人まで楽しめるようになってます。

イベント1日目、自分は300レベル(中級者向け)のセッションに参加しました。

セッションのタイトルは「Alexa, Where’s My Car? A Test Drive of the AWS Connected Car Reference」。 車両や運転にまつわる多様なデータをAWS IoTで集めてビックデータ化する、というざっくり言えばそんな内容でした。 普段自分たちが触れるAPI Gateway、Lambda、DynamoDBなどのサービスがこういった用途で使われていると考えると、とてもワクワクします。

スライドは後日発表されるかと思うので、発表され次第こちらにもリンクを貼ります。

JapanExploring Night

夜はJapan Exploring Nightに参加しました。

こんにちは、エンジニアの吉田です。

前回そうだ、HTTP/2に移行しよう(OpsWorks編)の記事を執筆しましたが、今回はその続編となります。 (前回から時間が経ってしまい申し訳ないです汗)

前回はHTTP/2に移行する為にAWS OpsWorksを用いたChef12スタックでの シンプルな環境を構築するところまでお伝えしました。 しかし実際はChef12スタックは、Chef11以前のスタックと違い それまでのレシピの運用方法を変えなければなりません。 今回は、現場でのOpsWorks Chef12スタックにおける課題の解決にフォーカスした実践編となります。

実践編

その1. OpsWorksのChef12スタックでコミュニティクックブックを利用したレシピを実行する

Chef12スタックで最も注意しなければならない点は、レシピを実行する際に 利用するコミュニティクックブックの参照が自動的に行われなくなったことです。 試しにコミュニティクックブックを利用したレシピをそのまま実行しようとしたら 「コミュニティクックブック?そんなの見つからないよ！」と怒られます。

なので解決方法としてはコミュニティクックブックを含んだクックブックアーカイブを事前に作成し s3にアップロードした場所を参照するようにします。

コミュニティクックブックを含んだクックブックアーカイブを作成

[前提条件] アーカイブ作成にはBerkShelfをインストールしている必要があります。 もし無い方はChefDKをインストールするか、もしくはGemでBerkShelfをインストールしてください。 ChefDK: https://downloads.chef.io/chefdk Gem: gem install berkshelf

[手順] 1.　ローカルでクックブックのディレクトリに移動する

2.　berks packageコマンドを実行してアーカイブを作成する デフォルトだとcookbooks-1506749951.tar.gzといったタイムスタンプ付きのアーカイブが出来上がります。 もしファイル名を指定したい場合はberks package {ファイル名}.tar.gzのようにコマンドを実行します。

3.　アーカイブを格納する為のs3バケットを作成する

4.　手順3で作成したバケットにアーカイブをアップロード

AWS CLIのS3コマンドが便利です。 aws s3 cp cookbooks.tar.gz s3://{バケット名}

実行後、S3にアーカイブファイルがアップロードされていることを確認します。

こんにちは、チーム活性化サービス「Goalous」のリードエンジニアを務めている吉田です。

今回はGoalousがHTTP/1.1からHTTP/2に移行した経緯と実際にどのように移行したのかをお話します。

なぜ移行したか

僕達は先月までサービス全体の大規模なパフォーマンス改善を1ヶ月半以上かけて行っていました。

Goalousは以前からレスポンスの悪さがかなり目立っていて、「表示速度が遅い」という意見が多く寄せられていました。 開発チームとしてはユーザーのストレスを軽減してサービスの使い心地を向上させたい、 「サクサク動かせるようにしたい」という思いが前々からありましたが ただ機能追加・改善がどうしても優先的になってしまい手をつけることが出来ずにいました。

しかしサービスを有料化する前にはどうしても対応したかったこともあり、 今年5月にチームの総力をあげてサービス全体のパフォーマンス改善に取り組むことが決定しました。 HTTP/2への移行はそのパフォーマンス改善の一つの取り組みです。 HTTP/2のメリットの詳細は今回は省略しますが、詳しく知りたい方はこちらを参照下さい。

HTTP/2への移行を決めたのは、リクエストとレスポンスの多重化等のメリットを享受したかったのと、他にもう一つ僕達にとって重要な理由がありました。 それはAWSの問題です。

GoalousではAWSのOpsWorks(Chefを使用してクラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービス)を使用しています。

OpwsWorksはOpsWorksスタックとOpsWorks for Chef Automateの二種類があり Goalousで使用しているのはOpsWorksスタックです。

OpsWorksのスタックはChefのバージョンが11か12によって明確に区別されます。 僕達はずっとChef11のスタックを使用していましたが、もうそろろそろChef12にバージョンアップしたかったので 今回のHTTP2/移行が良い機会となりました。

あとはロードバランサーがELBではなくALBじゃないとHTTP/2を使用出来ないので思い切って Chef12+ALBの全く新しいスタックを作ることに決めました。

どう移行したか

GoalousのChefのレシピは残念ながら公開出来ないので、本記事においてはあくまで OpsworksのChef12スタックとALBをどう構成してHTTP/2を実現するか に焦点を絞り、サンプルのChefレシピを使ってミニマムな構成の手順を説明します。

参考：Use Application Load Balancers with your AWS OpsWorks Chef 12 Stacks

Step1.ALB作成

基本的にはAWSの公式ドキュメントに沿って作成します。

ただしステップ 5: ターゲットグループのターゲットを設定するはスキップしてください。 インスタンス作成とターゲットグループへのターゲット登録はOpsWorksで行います。

Step2.OpsWorksスタック作成

OpsWorksのダッシュボードページで、スタック追加ボタンをクリックします。

スタック追加ページに遷移後、まずChef12 Stackを選んだ上で、

こんにちは、インフラ担当の赤川です。

AWSの最新情報（英語版）にて、StorageGatewayを利用してEC2からS3マウントが可能になるとのアナウンスされました。

今回のアップデートにより、これまでの問題が解消できるのかベンチマークを取ってみました。

準備した環境

クライアント

比較するために以下A〜C3つのインスタンスを準備しました。

A.FileGateway経由でS3バケットをnfsマウントしたディレクトリをDocumentRootとしたインスタンス B.s3fsでS3バケットをマウントしたディレクトリをDocumentRootとしたインスタンス C.ローカルディスク内にDocumentRootを配備したインスタンス

各インスタンスにhttpdをインストール。 サーバ毎にDocumentRootを変更。

StorageGateway

Gatewayの要件はこちら

・・・なのですが、 読まないで進めたらいつまで経ってもGatewayインスタンスに接続できませんでした。 sshでGatewayインスタンスに接続すると、ご丁寧にvCPUが足りんと警告が。ちゃんと読んでスペックを確認しましょう。 （この画像はCPUでWarningですが、メモリ足りない場合はCriticalが出ていました。）

ちなみにGatewayインスタンスへのssh接続ユーザのデフォルトは「sguser」です。

S3

マウントするバケットを事前に作成しておきます。

FileGateway設定

まずはStorage GatewayのメニューからFile Gatewayを作成します。

GatewayのタイプはEC2を選択します。 赤枠で囲ったボタンをクリックするとEC2起動画面が開きます。

どうやらGateway用のAMIが用意されているようです。 前述の注意点を気にしながらインスタンスを作成します。

インスタンスを作成したらFile Gatewayの画面に戻ります。 Gateway IPアドレスを求められるので先ほど作成したインスタンスのIPを指定します。 続いてアクティベートも実行されます。

次にファイル共有の設定を実施します。 作成したGatewayを選択して「ファイル共有の作成」をクリック。

マウントするS3バケット名を入れます。 また、S3へ接続できるIAMロールも設定しておきます。

こんにちは。

インフラ担当の赤川です。

現地11/30はKey Note Day1でした。

本日発表された新しい情報を簡単に書いていきたいと思います。

コンピューティングサービス

Light Sail

サーバなど利用したことのない方向けのVPSサービス。 できるだけ簡単にインスタンスを起動できる。 データ通信量などを含めた月額定額で、使いたいサービス（wordpress）を選択することができる。

T2

瞬間的なCPUバーストを出すことができるインスタンスである T2インスタンスの新しいタイプが追加されました。

R4

R3の後継ファミリーとして、R4が発表されました。 最大搭載メモリは488GBとなります。

I3

I2の後継ファミリーとして、I3が発表されました。

C5

C4の後継ファミリーとして、C5が発表されました。 コンピューティングの集約型ワークロードに最適なタイプです。

Elastic GPUs

EBSと同じ感覚で、既存のインスタンスに対してGPUをアタッチすることができるようになります。 3Dモデリングなど、幅広いグラフィックワークロードを実行したい場合に向いています。

F1

プログラマブルなハードウェアであるFPGAを利用可能なインスタンスファミリであるF1が発表されました。 自身でカスタムハードウェアアクセラレーションをプラグラム可能で、FPGAイメージを作成し、 ハードウェア上でカスタムロジックが動作する仕様となります。

DBに関するアップデート

Amazon Athena

EMRやElasticSearchを利用するのはちょっと高価すぎるという場合の分析サービスで、 簡単なクエリを投げて分析/解析することができます。 ANSI-SQLをサポートしているので、特殊なスキル不要。

今後、S3を中心としたデータレイクを構成していくことをオススメしていました。

Aurora PostgreSQL対応

2014年に発表されたAuroraがPostgreSQL互換対応版もリリースされます。 PostgreSQLでAuroraを利用したかったお客様には朗報ですね。

こんばんは。 インフラ担当の赤川です。

本日も引き続きre:invent2016 Key Note 二日目の模様をお届けします。

Deploy

AWS OpsWorks For Chef Automate

Full ManagedなChef Serverとして、AWS OpsWorks For Chef Automateが発表されました。 OpsWorksのStackで操作し、バックアップやソフトウェアアップグレードまでManagedされ、 これまで運用の負荷となっていたChefサーバーの管理が容易になります。

Amazon EC2 Systems Manager

EC2を管理するサービスとして、Amazon EC2 System Managerがリリースされました。

コマンド実行やインベントリ、Windows Serverに対するパッチ管理などが実現され、 運用の手助けになりそうです。

AWS Code Build

コード管理のCode Commit、DeployのCode Deplyの足りないピースとして、 デプロイを請け負うAWS Code Buildが発表されました。

課金体系はビルドされてから処理が終わるまでの分単位課金となるようです。

DevOps

AWS X-RAY

AWS re:invent2016 Global Partner Summit

はじめまして。 インフラ担当の赤川です。

LAS VEGASで開催されているAWSのユーザカンファレンスであるre:inventに来ています。 昨年は弊社からは1名の参加でしたが、今年は私を含むインフラメンバ3名で参加しております。

本日はグローバルパートナーサミットが開催されました。

パートナー企業に対するメッセージとして、次のメッセージが響きました。 （同時通訳で聞いていたので齟齬があるかもしれません。）

フォーチューン100に入る企業の90%がAWSを利用、またパートナー企業が様々な形でサポート していることも見ればわかるように、顧客は専門的なAWSの知見がなく、それを実現してくれる パートナー企業を必要としている。

つまり顧客がわからないこと＝パートナー企業にとっては最大のチャンスである。 こういった要望に応えられるプロフェッショナルな人材に投資する企業が勝ち残っていくと感じている。

これは本日発表された、Partner Solutions Finderなるサービスと紐づいた メッセージなのかと思っています。

Partner Solutions Finder https://aws.amazon.com/jp/partners/find/

検索キーワードを元にパートナー企業を探すことができる検索サービス。 そして、検索結果からダイレクトにパートナー企業へ問い合わせることができるようです。

AWSのサービスを知り尽くし、最適なシステムを提供できる企業は検索候補として引っかかる可能性が 上がり、今まで以上に多くの仕事を受注できる可能性が広がる。

弊社はAdvanced Partnerとなっておりますが、これまで以上にサービスを提供できる幅を広げ、 精進していきたいと思います！！ 余談ですが、今回の参加者特典はパーカーとecho dotでした。

明日以降もKey Noteを中心にレポートしたいと思います。

こんにちは、平形です。

先日8/24、弊社で4回目の外部向けの勉強会を開催しましたので、その様子をご報告させていただきます。

今回はAWS関連のトピックを私、平形と同じく弊社エンジニアの赤川がお届けしました。

今回４回目となる勉強会も盛り上がりを増してきた事もあり、弊社代表の中村が自ら挨拶を買って出てくれました。

今回もたくさんの方々にご参加いただき、大変嬉しく思っています。

内容

今回は、

• AWSを使っているならOpsWorksでDevOpsしよう！ by 平形
• AWS運用アレコレ by 赤川

の２本立てです。

イベントページはこちらのconnpassページにて

弊社では、AWS, GCP, AzureなどクラウドリソースをMSP事業、自社サービスで積極的に活用しております。今回はその中からAWSについてお話ししました。

今回の勉強会のもう一つの特徴は、スピーカーの２人とも今年第一子が誕生した新生育児パパという事です。育児と仕事の両立をして日々業務に精を出しています。

株式会社ISAOは、そんなイクメンエンジニアを応援しています！

AWSを使っているならOpsWorksでDevOpsしよう！ by 平形

AWSのデプロイサービスの一つOpsWorksについて実際の業務で得た知見を発表しました。

AWS運用アレコレ by 赤川

AWSの障害対応など日々1,000台単位のEC2の運用を行なっている中から得られた運用のコツなどを発表しました。

懇親会の様子

秋葉原名物の万世のハンバーグサンドです。

大変美味しく頂きました。

今回も多彩な領域のエンジニアの方々とお話しでき、有意義な交流会となりました。

2015年10月23日にアイティメディア主催**「主導権はユーザー側が持つ　企業のためのAWS徹底活用セミナー」**に登壇いたしました。

当日セミナーにお越しいただけなかった方にもお伝えできるよう本ブログにてコンテンツとしてお届けいたします。

セミナー概要

AWSの利用を躊躇されている方々へ

株式会社ISAO infra R&D プロジェクトリーダー 片貝 力也

本日はAWSの利用を躊躇している方々に向けて、利用当初の注意点や問題になりやすい事項を簡単に紹介させて頂きます。具体的な実例をもとにご説明させて頂きたいと思いますが、既に利用いただいている方々にとっては物足りない内容になってしまいます。その点、予めご了承ください。また最近ニーズが高まっているAWSでのセキュリティ対策についてもご紹介いたします。

EC2以外のサービスを利用しますか？

AWS（Amazon Web Searvices）を利用される予定の方々に質問です。 EC2以外のサービスを利用しますか？

もちろんEBSやELB、S3なども利用しないとサービスとして成り立たないかと思いますが、現状AWSにて構築を検討する際に、まずAWSで提供しているマネージド込みのサービスをどこまで使用するかが一つの重要なポイントになります。EC2上に自前でミドルウェア環境を構築していくのか、RDSやElastiCashなどミドルウェアまで揃えているマネージドサービスを利用するのか、どこまで利用するのか一度検討ください。ただマネージドサービスを利用することで構築の手間が大幅に省けますし、運用の手間も簡略化されるため、工数が減りコスト減にも繋がりますので、利用される事を通常お勧めします。

しかし、1点気を付けなければならないのがベンダーロックイン（※）状態です。 数年毎に別のシステムへの移設を検討しなければならない場合は、マネージドサービスを利用していると移設検討が非常に困難となってしまいます。ただAWS環境から他環境への移設メリットは無い、もしくは薄いケースが殆どだと思いますので、現状ですとマネージドのサービスを躊躇せずに利用して問題ないと思います。またAWS環境にて安定的なサービス運用をする為にもマネージドのサービスを利用する事は近道となります。

（※）ベンダーロックイン 特定の環境・技術に固定され、他との互換性が損なわれるとこと

ただシステム環境以外にも構築運用メンバーの技術スキルもAWSに踏襲・専属化していってしまいますので、昨今のインフラメンバーでは、オンプレミス環境のネットワーク設計や導入作業が出来ないといった事態も発生してます。

インフラエンジニアを抱えていらっしゃる企業様は、運用リソースの配置や今後のスキルパスまで考えていくことが必要です。

AWSの月額費用って本当に安いの？

AWS利用で発生する月額費用は、規模がある程度大きくなると決して安くは見えません。

特にオンプレミスで構築した場合のCPUのコア数やハードウェアのパフォーマンス等を、そのまま踏襲してAWSで試算をすると、1年や複数年のスパンでハウジング費用と比較すると高くなるケースが多々あります。ただし、これは単純に発生する月額費用を比較した場合の話なので、実際は見えにくい運用でのコストを加えて比較すべき内容です。

AWSは構築運用だけでなく、設計や管理、オンサイト作業のコストを除外できることも大きなメリットとなります。 例えばデーターセンターに行く必要がないというのが分かりやすい一例です。それらを計算に入れると正しいAWS費用の試算ができます。 またインスタンスの稼働を100%ではなく、実負荷を想定した変動性でコスト試算できるとよりメリットが見やすくなります。

リザーブドインスタンスって？

さらに、AWSにはリザーブドインスタンス（RI）という年間契約でお安くなるプランもございます。 このRIは1年もしくは3年契約での割引サービスだけでなく、「リザーブド」の名前が示すようにインスタンスの起動が約束されます。 契約しているとインスタンスの数が確保でき、稀にある「リソースが枯渇していて必要なインスタンスの数が上がらない」といった心配も無くなります。

インスタンスの起動に失敗した場合、数分〜数十分待ってから起動させる必要があるのですが、RIは契約分のリソースが確保される事になります。 手動でオペレーションしている場合は大きな問題にはなりませんが、規模が大きくなり自動化等を取り入れていると、スムーズなインスタンスの起動は重要な課題となります。

AWSのメンテナンスってどうなの？

EC2のメンテナンスには主に2種類あります。

• アップデート用メンテナンス
• リタイアメント用メンテナンス

1つ目はAWSが実施するセキュリティアップデートです。こちらは特定のタイミングを指定し、AWS側が実施するメンテナンスとなります。なので環境や対象によっては、そのタイミングでサービスを停止、メンテナンスに切り替える必要があります。ただライブマイグレーション等で対応できる範囲も増えているようなので、今後は年に1回あるかどうかだと考えてます。

昨日に引き続き、2015/10/8 9:00〜10:30（現地時刻） に行われた keynote 中に発表されたプロダクトをお伝えします。

Amazon EC2 新インスタンス、X1, t2.nano

まずは EC2 の新インスタンス。X1 インスタンスは最大 100vCPU！/ 2TB メモリー！。クラウド上の IaaS の利用がインメモリ処理で実行するアプリケーションが増えてきたことに対応。SAP HANA などもターゲット。 ホスト側の CPU は Intel Xeon E7 v3 を採用しています。 t2.nano は 1vCPU / 512MB メモリーというスペック。上記のような要求がある一方で、t2.micro の 1GB メモリーでも大きいよ、というニーズが多いためと思われる。

Amazon EC2 Container Registry (ECR)

2015/10/7 8:30〜10:30（現地時刻） に行われた keynote 中に発表されたプロダクトをお伝えします。

Amazon QuickSight

Amazon発の高速で使いやすく、コスト効果の高い BI ツール。 ビッグデータや IoT と言った言葉が飛び交う中、UI/UX 部分に関しては個々で開発が必要でした。 これを使ってデータがあればすぐにでも BI を構築できてしまう代物。 データ解析には新たに「SPICE」という名のエンジンを開発。 また、SPICE からのデータエクスポートはDomo, Qlik, Tableau, Tibco等にも対応予定とのこと。

Amazon Kinesis Firehose

すでにプロダクト化されている Kinesis の派生版。今まで Kinesis にてストリームされたデータについて EC2 や S3 ひいては Redshift で利用する際、ユーザーが個々にアプリケーションを開発する必要がありました。 Kinesis Firehose を利用すればストリームデータを直接、簡単に S3 や Redshift にロードすることが可能になります。

おはようございます。インフラ宮下です。

AWSのVPCとオフィスをVPNで接続するケースは良くありますが、構成によってはダウンロードしたconfigではうまく動作しない事があります。 今回は、以下の環境の時に変更しなければいけなかった設定をまとめたいと思います。

１）AWSの接続環境

[shell]リージョン：シンガポール ルータ：YAMAHA RTX 1200 経路情報：Static[/shell]

２）VPNのconfigを確認

VPN Connectionsを作成した後にconfigをダウンロードすると設定項目として、IKE・IPSec・Tunnel Interface・Static Route の4項目がありますのでそれぞれの内容について確認しましょう。

・IKE

[shell] tunnel select 1 ipsec ike encryption 1 aes-cbc ipsec ike group 1 modp1024 ipsec ike hash 1 sha ipsec ike pre-shared-key 1 text y7Nn93e7fJHWQrUaabbccdd112233[/shell]

IKEについては、configそのまま流用で問題ないでしょう。keyは個々に違いますので正しいKeyにしてください。 トンネル番号は、既に「1」を使っている場合は違う数字にしてください。（以降のID表記も忘れずに変える）

・IPSec

[shell] ipsec tunnel 201 ipsec sa policy 201 1 esp aes-cbc sha-hmac ipsec ike duration ipsec-sa 1 3600 ipsec ike pfs 1 on ipsec tunnel outer df-bit clear ipsec ike keepalive use 1 on dpd 10 3[/shell]

Amazon RDS for Auroraでプレビューが始まりました。

Auroraとは…MySQLと互換性のあるデータベースエンジン(MySQL5.6)で、 高性能の商業用データベースの可用性およびスピードと オープンソースデータベースのコスト効率性および簡素性を併せ持っています。 Amazon Auroraは、MySQLの5倍の性能を持ち、 同様の機能や可用性を提供している商用データベースの10分の1の価格との事です。

現在プレビュー利用待ちです。

プレビュー利用したら感想等伝えようと思います。