AWS re:Invent2017 1日目 参加レポート
エンジニアの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に参加しました。 会社として普段お世話になってる企業様や、業務の関わりは無くてもAWSを使ったサービスを展開している企業様など、様々な方とお話させていただきました。 AWSを中心に人の輪ができ、そこでお互い好きなサービスについて語り合う、とても有意義な時間でした。 二時間があっという間でした。...そうだ、HTTP/2に移行しよう(実践編)
こんにちは、エンジニアの吉田です。 前回そうだ、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://{バケット名}...そうだ、HTTP/2に移行しよう(OpsWorks基本編)
こんにちは、チーム活性化サービス「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を選んだ上で、...EC2からStorage Gateway経由でS3をNFSマウント
こんにちは、インフラ担当の赤川です。 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ロールも設定しておきます。 完了するとmountコマンドまで表示してくれます。 親切ですね〜。 クライアントからGatewayインスタンスには接続できるようにSecurity Groupを適宜設定します。 後はクライアントインスタンスを準備し、httpインストールとDocumentRootをマウント先パスに変更しておきます。 abベンチを実行 マウント先にテストドキュメントを適宜配備し、httpdを起動しておきます。 s3fsやローカルディスクを利用したインスタンスも起動して各自ベンチを取ります。 Gateway経由でS3マウントしたインスタンスの結果 s3fsでS3マウントしたインスタンスの結果 ローカルディスク利用インスタンスの結果 数回ベンチしてみましたが、ローカルディスク利用時と遜色のない結果となりました。素晴らしい。 ただ、GatewayインスタンスがSPOFになることと、Gatewayインスタンスのスペックがそれなりに必要なので、 導入時に適したシステムなのか要検討です。...AWS re:invent2016 Key Note --- Day1 ---
こんにちは。 インフラ担当の赤川です。 現地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を利用したかったお客様には朗報ですね。 AI/ディープラーニング Amazonの商品おすすめ機能など、これまでもAmazonはAIを利用してきた。 Alexa&Echoなどの音声サービスに対するディープラーニング。 Amazon Rekognition ディープラーニングを利用した画像認識サービスとなります。 S3に格納した画像に対して解析を行い、状況、物体、顔情報に関するタグ情報を出力。 Amazon Polly テキストで省略した言葉（PPAP)なども解析し、省略している言葉も フル（PenPineappleApplePen）と発生してくれるサービス。...AWS re:invent2016 Key Note — Day2 —
こんばんは。 インフラ担当の赤川です。 本日も引き続き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 X-RAYが発表されました。 アプリケーションのどこがボトルネックになっているのか、レイテンシーなどを深掘りしてみること ができるようになり、アプリケーションの見える化を実現します。 Respond AWS Personal Health Dashboard AWS Personal Health Dashboardが発表されました。 これまで個別に通知されていた（インスタンスのメンテナンス通知等）が一元的に管理されます。 つまりアカウント自体で予定されているメンテナンス情報がパッとコンソール画面で確認することができるようになります。 パフォーマンスや可用性も確認可能とのことです。...AWS re:invent2016に来ています
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を中心にレポートしたいと思います。...勉強会を開催しました！「AWSを使っているならOpsWorksでDevOpsしよう！」、「AWS運用アレコレ」の二本立て
こんにちは、平形です。 先日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の運用を行なっている中から得られた運用のコツなどを発表しました。 懇親会の様子 秋葉原名物の万世のハンバーグサンドです。 大変美味しく頂きました。 今回も多彩な領域のエンジニアの方々とお話しでき、有意義な交流会となりました。 次回予告 日時：9/29(木曜日)19:00 予定 お題：使った気になるFirebase(仮) 場所：株式会社ISAO おわりに 弊社は今後も社外へ向けた勉強会を引き続き開催していく予定です。 勉強会テーマについても、参加者の皆さんのご意見を反映して幅広いジャンルにしていくつもりです。 connpassのISAO Meetupグループに是非ご参加ください！！ http://isao.connpass.com/ 最後になりますが、ISAOでは一緒にサービスを作ってくれるエンジニアを絶賛募集中です。 ご興味を持っていただけましたら、まずは気軽に弊社に遊びにいらしてください。 https://www.colorkrew.com/recruit/...AWS活用セミナー「AWSの利用を躊躇されている方々へ」
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回あるかどうかだと考えてます。 2つ目はハードウェア故障やリタイアメントによる、インスタンスのstop/startとなります。こちらは取り扱いインスタンス台数が増えるにつて対象となる可能性も高まりますので、わたくしの感覚ですと1,000台程度起動していると毎週どこかで発生する程度の頻度となります。ただこちらは指定された日までの好きなタイミングでstop/startをすれば良いだけなので、通常サービスへのインパクトはそれほど高くなりません。※ただ通常平日の4:00からとかに実施しますので、作業者が頻度によっては少々大変になります。 またインフォメーションは英文メールでとどきますので、見逃さないように注意が必要です。 Eventとしてもマネージドコンソールで確認できますので、弊社はAPI経由でEvent監視をしてアラート発報させてます。 上限緩和申請って知っていますか？ 意外に知られていないのですが、AWSには非常に多くの起動数や設定数の上限設定がなされています。 EC2インスタンスの起動数やEBSのトータルボリューム数、ELBの数、SecurityGroupの数等、それは多岐にわたります。 例えば、EC2インスタンスはタイプにもよりますが、20がデフォルトの起動上限数です。 よって、21以上のインスタンスを起動したい場合は、事前にマネージメントコンソールから上限緩和申請をする必要があります。 この上限緩和は少し時間を要しますので、構築作業の前日までには申請をしておいた方が無難です。...AWS re:Invent keynote DAY2
昨日に引き続き、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) いよいよ AWS のコンテナサービス利用が本格的になりそうだ。 今まで、docker コンテナで利用するイメージファイルは aws 上で管理、作成などができず、ユーザーが独自で管理する必要があった。 今回のアップデートでフルマネージドとなり、AWS 上でイメージファイルの保存、管理、デプロイが可能になります。 また、AZ を意識した配置、CLI などの提供も始まります。...AWS re:Invent keynote DAY1
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 にロードすることが可能になります。 QuickSight といい、Kinesis Firehose といい、ユーザーサイドの開発を必要とせず、やりたいことをすぐに実現できるようになります。 AWS Snowball 今回の製品発表の中で一番驚きを隠せないのがこれだ。 今までオンプレミスからクラウドへ移行したい、と思うユーザーにとって最大の障壁の一つであるデータ移行。 このデータ移行を安全に迅速に行えるようになるプロダクトが Snowball だ。 アプライアンス製品として提供され、配送の際発生するヒューマンエラーを排除する、とのことなので、物流としての Amazon のナレッジも生かされていると思われる。 1アプライアンス 50TB で提供され、複数個使用することで 100TB, 200TB と利用することが可能。 今までかかっていたデータ移行のための回線費用などの削減する。...AWSとVPN接続したら応答が無くなる時の対応
おはようございます。インフラ宮下です。 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プレビュー利用開始！
Amazon RDS for Auroraでプレビューが始まりました。 Auroraとは…MySQLと互換性のあるデータベースエンジン(MySQL5.6)で、 高性能の商業用データベースの可用性およびスピードと オープンソースデータベースのコスト効率性および簡素性を併せ持っています。 Amazon Auroraは、MySQLの5倍の性能を持ち、 同様の機能や可用性を提供している商用データベースの10分の1の価格との事です。 現在プレビュー利用待ちです。 プレビュー利用したら感想等伝えようと思います。...DevOps時代のアジャイルでスケーラブルな開発環境をVagrant, GitHub, Travis, Chef, OpsWorksで構築する
どうも。久しぶりです。 デベロッパーの平形です。 このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。 とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。 はじめに 私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。 この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。 この記事は以下の方には不向きです。 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。 これらに該当する方。お疲れ様でした。出口はこちらです。 この記事は以下に該当する方に是非読んでいただきたいです。 開発者、インフラ担当者の方。 これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。 サーバーの台数が多くなったらどうしよう。と悩んでいる方。 開発要員が急に増えたらどうしよう。と悩んでる方。 DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。 上記を実践してみようとしたけど、挫折してしまった方。 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。 本番反映が怖くて会社に行きたくない方。 サーバーが落ちる事が不安で夜も眠れない方。 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。 それでは、夢の扉を開きましょう。 レガシーな開発と運用 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。 公開環境のサーバー増設は１台ずつ手動でキッティングしている。 パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。 バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。 これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。 現代の開発と運用 現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。 素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。 近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？ バージョン管理 環境構築 セキュリティパッチの適用 バージョンアップ オートスケール 自動テスト 自動デプロイ 開発環境の配布 なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。...