ども、知らないことばかりの cloudpack の かっぱ (@inokara) です。 はじめに アプリケーションのエラーログも見逃したくない PlayFramework では特に設定を行わない限りは ${application.home}/logs/application.log にログを書き込むが、放っておくとローテーションも行われない…orz。後々泣かない為にもローテーションを行いつつ、ログの監視を行うにあたり監視対象のログファイル名は固定したい場合にどうすっかなーと思って試したメモ。 キモは LogBack 初耳の LogBack だが、PlayFramework ではデフォルトのロガーとして利用されている。 Logback Project log4j の後継という位置付けで log4j よりも柔軟な設定が出来るとのこと。今回は Logback の設定を修正した上で…冒頭と繰り返

こんにちは、cloudpack の 今岡 です。 lsyncd を使って、2台のサーバ上のファイルを双方向からの同期を検証していた時に、予期せぬファイル削除が発生しました。その謎と対処方法について迫ります。 lsyncdで双方向同期とは？ lsyncd は自分の特定のディレクトリを見張り、変更(ファイルの追加、変更、削除等)のイベントが発生した場合、それをトリガーに他のサーバへ伝搬したりすることができます。しかし、 lsyncd はあくまでも自サーバのファイル変更を捕まえるだけなので、相手のサーバに起こった変更はわかりません。 そこで、例として2台のサーバでお互いに lsyncd をかけることにより、2台が全く同じ状況を作ります。下図のような構成です。(絵はAWSですが、別にAWSに限った話ではないです。) lsyncインストール CentOS 6系の場合は、下記を参考にインストールできま

手順は４つになります。 Amazon EC2 Eメール上限緩和申請手順 逆引き(rDNS)設定申請手順 Amazon EC2 Eメール上限緩和 + 逆引き(rDNS)設定申請手順 逆引き(rDNS)設定解除申請手順 手順を区分けします。 申請 Amazon EC2 Eメール上限緩和申請手順 逆引き(rDNS)設定申請手順 Amazon EC2 Eメール上限緩和 + 逆引き(rDNS)設定申請手順 解除 逆引き(rDNS)設定解除申請手順 まとめ 申請は、3のAmazon EC2 Eメール上限緩和 + 逆引き(rDNS)設定申請手順だけではありません。1と2の2回でもよいということです。解除もできます。 間違って申請した場合も、訂正して正確な情報をAWSに申請しましょう。そして、使わなくなった場合も4の解除申請を忘れずに。 元記事はこちらです。 「EC2インスタンスからメール送信のための準備

こんにちは cloudpack の 磯辺 です。 Amazon RDSは、自動バックアップ機能があって大変便利である。自動バックアップは、ポイントインタイムリカバリ用のデータの他に、定期的にスナップショットも作成する。 そのため、RDSのスナップショットには属性があり、自動バックアップによるスナップショットと、ユーザによって取得されたスナップショットの区別ができるようになっている。それぞれ、automatedとmanualという属性値となる。 RDSの自動スナップショットは、RDSインスタンスとライフタイムが同じであり、インスタンスを削除すると、automatedスナップショットも消えてしまう。RDSは、インスタンスを削除する際に、ファイナルスナップショットなるものを作成できるのだが、あくまで最終的な状態のみが残せるだけで、ポイントインタイムリカバリのように、過去のデータから戻すことは出来

シンジです。先日Slackのアップデートがありまして、Windows AppやMac App、iOS Appが更新されました（Androidどこいった）。いくつかの機能が追加されましたが、特に目を引く「なんか、いいねっぽい機能」をご紹介したいと思います。 Add a reactionという機能 発言を行う前ではなく、発言後に、メッセージの右側にあるアイコン↓ をクリックして、 これをクリックする。後はもうやりたい放題です。 どっちの絵文字か選んでねってアンケート取ったり この発言を確認したらチェックしてねってTodoにしたり いろんな使い方が出来そうですね〜。 誰がリアクションしたのかが分かるのと（名前の一覧が出る）、誰の発言に対してもリアクションが出来るので（自分の発言じゃ無くてもリアクションを追加出来る）、よりSlackが楽しくなりそうですね！ 他にも機能追加はあるようで チャンネルに

CloudFront(以下CFと略)を始め、CDNを利用するにあたり、まず注意することは、キャッシュを削除する手段を確立することです。CFはinvalidationをURL毎に発行することにより、このキャッシュクリアを実現していましたが、昨年、ワイルドカード (e.g /image/*) で一気にURLを指定し、クリアすることができるようになりました、が、一部の環境において不具合があり、それをAWSサポートに連絡、修正してもらいました。今はすでに治っているので問題ありませんが、CFの理解のために記述しておきます。 不具合ってどこよ？ /8146 この問題を 勝手に古いヘッダのキャッシュ問題 と呼称します。 発生のメカニズムは CFにキャッシュされる、このとき、レスポンスヘッダもキャッシュされる TTLが切れて、オリジンにリクエストが飛ぶ オリジンのヘッダだけが変わっていて、コンテンツに変化

tl;dr 無料で可能な限り安く Node.js アプリを動かしたい！！！！ので app.yaml を書きなおした。 先人の知恵 Google App Engineを無料で運用する方法（2016年版） – koni blog しかし 先人の知恵そのままに Node.js アプリをデプロイしようとすると ERROR: (gcloud.preview.app.deploy) Error Response: [400] VM-based automatic scaling should NOT have the following parameter(s): [min_pending_latency, max_idle_instances] と怒られてしまった。どうやら言語によって app.yaml に定義すべき内容の仕様が微妙に違うらしい。 こちらは PHP app.yaml Referenc

俺です。コミュ症です。 最近EC2原人を脱却すべくAPI Gatewayのドキュメントを読んで電卓アプリケーションを作りました。 作成した電卓アプリケーションを俺の考えた最強のドメイン名でアクセスできるようにして、最強のアクセス制限を設定したいと思います。 図は端折ります。 API GatewayとLambdaの準備 API Gatewayのドキュメント に従って作成します。 コレを読んで手を動かせば誰でもサーバレス童貞を捨てることができます。最高。 Route53の準備 かっこいいやつを設定しましょう SSL証明書の準備 AWS WAFはCloudFrontのトラフィック制限サービスなのでCloudFrontを準備します。 CFに設定するSSL証明書はACMで準備します。 バージニアリージョン(us-east-1)に *.gluerecord.oreda.be という名前で準備しました。

STNSで何が課題やったん？ お客さん「十数台規模でLDAPとか面倒だよね。管理とか冗長化とかも考えたくないし。」 俺「STNSでもサーバ側のインフラ管理面倒だな、、。やりたいのはユーザ管理でサーバ管理じゃないし」 俺「STNSのバックエンドははRESTで受けてJSONで返せば何でもいいのか。API GatewayとDynamoDB使えばバックエンドをサーバレスに出来るんじゃ？」 実現したこと STNS＋AWS API Gataway＋DynamoDBでサーバレスユーザ統合管理 構成 特徴 STNSでシンプルにユーザの統合管理を実現 シンプルで軽量 既存のPAMも併用可能 バックエンドはRESTであれば自由 バックエンドのSTNSサーバはAPI GatewayとDynamoDBを利用することでサーバレスで高可用性 冗長化とか考える必要無し（もちろん止まることはある） DynamoDBは複数

シンジです。シンジの勤めるアイレット株式会社は、ISO:27001/ISMSと、ISO:20000/ITSMSに続き、クラウドセキュリティの認証規格であるISO:27017/ISMS-CSを取得しました。アイレット及びcloudpackのユーザー様は、追加費用無く、これら各セキュリティ認証の恩恵を享受することができます。 AWS APN コンサルティングパートナー(SI)企業としては 国内初です。 ISMS-CSとはなにか 国際標準化機構(ISO)より2015年に発行されたクラウドセキュリティに関する国際規格を、日本国内の監査団体による監査で適用可能としたものです。この規格は、クラウドサービスの提供及び利用に関する情報セキュリティ管理策のためのガイドラインで、提供者側と利用者側で監査内容は異なり、今回アイレット株式会社は、その両方の監査を受けました。 ISMSをベースとしているため ISM

tl;dr 整理した。 大前提 最低でも IAM Policy の AmazonEC2ContainerRegistryReadOnly をつけた IAM Role 又は IAM User を使う EC2 上での手順 前提 EC2 には 管理ポリシーの AmazonEC2ContainerRegistryReadOnlyをつけた IAM Role が付いている docker login コマンドを取得する aws --region ap-northeast-1 ecr get-login docker login する docker login -u AWS -p xxxxxxxxxxxxxxxx -e none https://0000000000000.dkr.ecr.ap-northeast-1.amazonaws.com docker pull する docker pull 000

Hello〜、ナスです。 先日、社内で勉強会があったんですが、某案件で一番勉強になったことを発表するために資料作ってたら大事なことを思い出したので、ここでも書いておこう。 キャッシュすることはとても大事なこと CloudFrontでオブジェクトをキャッシュすることはとても大事です。(動的コンテンツは除く そもそも、CloudFrontの大きな役目は、 バックエンドのwebサーバの負荷を抑える 世界各地にあるエッジロケーションにもキャッシュを配置してレイテンシを低く抑える だと思っているので、キャッシュしないとCloudFrontを使う意味があんまし無いんです。 静的サイトなのになぜかキャッシュしないと言われた 「12:00ちょうどにあるページを公開したいから、CloudFrontでキャッシュしないようにして」 ある時、この言葉を聞いて脳みそが？？？ってなったのを覚えてる。htmlしかないの

シンジです。といっても実は初めてじゃないのですが、AWSの監査は基本英語で、毎年内容が大幅に変わってくるので油断できない内容となっており、監査慣れしているさすがのシンジもヒーヒー言わされるわけです。 なぜAWS本体がわざわざ日本のホゲホゲ企業cloudpackを監査するのか いろんな大手IT企業が「パートナー制度」を作っているのはよく知られていますが、もちろんAWSも「AWSパートナーネットワーク（APN）」というものを立ち上げており、業種別や分野別、そして実績などを考慮して、格付けをしているわけですね。 cloudpackはAWSのシステムインテグレーターとしては最上位に位置する、日本初のAPNプレミア コンサルティングパートナーとして、これまで4年連続で認定されています。 このAPNの発表は、AWSの大型イベントである「re:invent」のメインセッションで発表会が行われるのが通説な

その名も Anomalynks Anomaly(異常) + Link(リンク)の造語。 https://github.com/cloudpack/anomalynks つくった背景と解決できる課題 PM < この前つくったあのサイトやねんけど、ちょっと部分部分きりとって別のサイトにしたいんよねー PM < でも１ページ消したら他のページからリンクされてるの切れちゃってつらみあるからどうにかして? ぼく < はい ＞　リンクチェッカーみたいなのつくろう　＜ PM < あとついでにページ間の関係性みたい PM < どうせならデザインチームでもできるように可視化してや ぼく < はい ＞　可視化しよう　＜ PM < 管理画面とかでログイン必要だから ぼく < はい PM < Seleniumは重いからブラウザの拡張的なのがいい ＞　ChromeExtensionに　＜ PM < ドメインまたぐか

cloudpackでは、4種類のホワイトペーパーを公開しているのをご存知でしょうか？ AWS Summit Tokyo 2016に1,000部ずつ持ち込んだら、あっという間になくなってしまい、いま絶賛増刷中です。 重版出来！ありがとうございます！（パンッ！←一本締めの音） 4作目の「cloudpack専用線接続ホワイトペーパー」が完成した頃、筆者の席の近くにふらりと現れた鈴木宏康CTOが、「ホワイトペーパー戦略、なんかいい感じになってきたね」と満足げに言いました。 ( ﾟдﾟ) ｶﾞﾀｯ!! ホワイトペーパー戦略ってナンすか！ ちょっと聞かせてください！ と急遽、突撃インタビューをすることにしました。 cloudpackのホワイトペーパー戦略 あのー『ホワイトペーパー戦略』って初耳なんですけれど あーごめんごめん。カッコつけて『ホワイトペーパー戦略』って言ってみたら、耳障りよかったもんで、

こんにちは後藤です。かなり大きめな台風がくるとかで、今日の朝は身構えてたのですが肩すかしを食らっちゃいましたね。打ち合わせなども空いたのでこの時間でブログを書こうかと。それでは先週気になったクラウド関連ニュースをまとめます。 AWS WAFでHost Header +IP Addressでアクセス制限してコミュ症ウェッブアプリケーションを作ろう CloudFront→WAF→API Gateway→Lambda経由でURLによる計算機実装。でもセキュリティなど含め実装がしっかり書いてあるｗ MackerelでDockerコンテナの起動状態を監視する 正式にDockerに対応してないMackerelでプラグインによる監視実装。起動状態のみだけのようだけど簡単でイイ感じ。 Amazon Web Services の本気がみたいか !? スピードと高可用性を両立したゲームインフラの構築と事例 A

中国で書かれた伝記歴史小説『水滸伝』に登場する百八星の豪傑たちが集う『梁山泊』に例えて、cloudpackに集結するエンジニアを『梁山パック』として、ここにその個性豊かな表情を順にお伝えしていきたい。 プロローグ きょう登場するメンバーは、cloudpackエンジニアの比嘉東一郎だ。社内に『比嘉』姓が複数いるので、みんな彼のことを『東一郎（とういちろう）さん』と呼ぶ。 東一郎のインタビューで、この『梁山パック』も3人目だ。私自身がインタビューにも慣れてきたのと、虎ノ門オフィス周辺ばかりだとすぐに飽きてしまいそうな気がしたので、「行きつけの店に呼んでください」なんて東一郎にリクエストをしてみた。 東一郎から指定された場所は、大江戸線の大門駅から徒歩数分のところにある居酒屋『よござんす 侍』だった。どうやら自宅から近く、文字どおり行きつけの店らしい。 19時過ぎ、オフィスから向かうことにする

みなさん360度の写真を知っていますか？ もしかしたらどこかで見たことあるかもしれませんね。これまで多くはRICOHのTHETA向けの共有サイトがあって、そこから見えていたかもしれません。ところがFacebookがタイムラインで360度またはパノラマ写真として取ったモノをアップロードしようとすると、360度見回せるようなインターフェイスを提供してくれるようになりました。 カメラで普通に撮った例 THETA Sの場合 ちょうど今San Franciscoへ出張ついでにBox本社、そしてGoogle本社へ行ったときの写真を撮ってみました。Google社オフィスのとある場所で撮った写真をRICOHのサイト経由で埋め込むとこんな感じです。 In the middle of huge Google campus #theta360 – Spherical Image – RICOH THETA 画像

ServerlessConf Tokyo 2016のライブ配信を行ないました。 記録済みの各セッションの映像配信も行うことになりましたので、以下にまとめます。なお当日のスケジュール詳細はこちらをご覧ください。 Keynote: Go Serverless, Compute Only When it Matters! by Olivier Klein – Amazon Web Services Serverless with Native Application for Newspass by Yuki Matsumoto – Gunosy Event-driven and Serverless Computing with OpenWhisk by Dr. Andreas Nauerz – IBM Lunchtime Speakers Session !! Unlimited Framew

『オウンドメディアの先輩から学ぼう！』第2回では、第1回にお話を伺ったシックス・アパートの壽さんからのご紹介で、フリーランスとしてさまざまなオウンドメディアの編集者をされている『アミケン』さんこと鈴木健介さんをお訪ねしました。 アミケンさんは、かつてオールアバウトでディレクターやプロデューサーを経験され、その後、さくらインターネットに転身。広報やWebマーケティングに従事する中、オウンドメディア『さくらのナレッジ』の初代編集長を担当されました。現在は、フリーランスの編集者として、数々のWebメディアの運営や執筆に携わっていらっしゃいます。 複数のメディアの編集者を兼務されていて、多忙を極める鈴木さんから待ち合わせに指定された場所は、意外にも東京都文京区の『根津』。根津と言えば東京の下町風情が残る『谷根千エリア』の一角で、文化的な香りはするものの、あまりビジネス臭のしないエリアです。その日は

tl;dr 定期的に Elasticsearch に問い合わせを行うバッチスクリプトで Elasticsearch への問い合わせ回数を減らしたい memo 状況 Amazon ES に保存されたログを検索するバッチスクリプトで特定の ID 毎に日付を範囲してログの件数を取得する 当初は ID が少なかったのであまり意識していなかったけど、テストで ID を増やしていったところ CPU 負荷も上がるし、たまに Amazon ES への接続エラーも発生している（認証辺りも絡んでいるかもしれない） ID 毎に Elasticsearch に問い合わせを行う実装にしていた（先に気づけよ的な話ではある） 戦略 www.elastic.co Multi Search API で実装すれば良さそう。 Multi Search API を使う前 以下のような感じのスクリプトで ID 毎に Elaseti