Posts

Atehna JDBC ドライバで Credential を明示的に指定せずに Athena にアクセスする

少し前まで対応していなかったのか、 JDBC ドライバで Athena にアクセス する際に Credential を明示的に渡さず、EC2 インスタンスなどに付与されているロールの権限でアクセスする方法が探しても見つからなかったのですが、(いつからかはわかりませんが) 今はできるようになっていました。 これで Credential の管理を気にせずに Athena JDBC ドライバが使えます。 How to configure aws_credentials_provider_class に com.amazonaws.athena.jdbc.shaded.com.amazonaws.auth.DefaultAWSCredentialsProviderChain を指定する。これだけです。 EC2 でも Lambda でもこれで OK。 How it works JavaDoc によると、DefaultAWSCredentialsProviderChain クラスは 環境変数 Java のシステムプロパティ ~/.aws/credentials ECS、EC2 のインスタンスメタデータ を探してアクセスキー ID、シークレットアクセスキーを取得するように動作します。AWS CLI の Credential を探す動作と似てますね ( boto3 っぽい感じ)。 このクラスを使うと、特にプロパティファイルや ~/.aws/credentials で認証情報を指定していない場合、EC2 の場合はインスタンスメタデータから、Lambda の場合は環境変数からアクセスキー ID、シークレットアクセスキーを取得し、EC2 インスタンスや Lambda についているロールの権限で Athena にアクセスできるようになります。 ちなみにこの DefaultAWSCredentialsProviderChain を使った方法、今の所は AWS Developer Guide では Undocumented の模様。Athena JDBC ドライバのドキュメントには InstanceProfileCredentialsProvider を使った方法 は書いてありますが、このクラスはあくまで EC2 インスタンス用 (インスタン

Solution Architect Professional に合格しました

2017/4/15 に Solution Architect Professional にチャレンジし、なんとか合格しました。2 年経ったら更新しないといけないので、2 年後の自分に向けて備忘録的なものを残しておきます。 どういう試験か Associate は AWS の各サービスが提供する機能や使い所を聞いてくる問題が多く、対策本もあるので、ざっと勉強すれば割といけてしまいます。 一方、Professional は多くの問題が、何らかの前提条件や制約条件と、システム構築や改修に関する要件が与えられ、その上で AWS を使って要件を満たすにはどのような設計やサービスの使い方をすべきか、という点を問われます。 例えば、 オンプレで多層 (Web レイヤー、APP レイヤー、DB レイヤー) の Web システムを運用しているお客様がいる Web レイヤーでは静的コンテンツに対するリクエスト、APP レイヤーでは動的コンテンツに対するリクエストをさばいている キャンペーンを開催したところ、ピーク時に最大 XXX rps のリクエストがあり、Web レイヤーでリクエストを捌き切れないという問題が発生した 次のキャンペーンが一週間後に迫っている お客様は AWS を使って可用性を確保したいと考えている どのような提案ができるか みたいな設問に対して、AWS を使ったソリューションが選択肢で与えられている、という感じです (実際こんな問題が出たわけじゃないです。ただの妄想です)。 選択肢には AWS じゃそんなのできないよ (そんな機能ない) というのが紛れている場合もありますが、どれをとっても実現は可能で、お客様の要件やステークホルダーが最も気にしているポイントを満たす上でベストな選択肢はどれか選べ、というものも結構多いです。 なので、サービスの機能を勉強してそれぞれ何ができるのか知っているだけではきつくて、設問の状況をしっかり理解して適切なソリューションを選べないといけないです。 上の妄想問題の場合だと、次のキャンペーンが一週間後となっているので、フルに AWS に移行するようなソリューション (CloudFront + ELB + EC2 + AutoScaling + RDS) は多分期間的に NG ですね。 Web レ

「Cassandra: The Definitive Guide 2nd Edition」を読んだ

新しい概念をいきなり英語で学ぶのはハードルが高いということで、以前買ってパラパラめくったっきりになっていた 日本語の第1版 を読んだ後に 第2版 に手を出したので、結局トータルで2ヶ月近くかかってようやく読み終えました。 元々は前職でWebサービスを開発していた時、データストアとして採用するかどうかの検討のために読み始めたのですが、転職してしまったため本来の目的を果たすことはありませんでした。が、分散システムのアーキテクチャについては非常に参考になりました。分散についてはまだまだ知らないことが多く、もっと勉強しないといかんなぁと思わされた書籍でした。 TOC Beyond Relational Databases Introducing Cassandra Installing Cassandra The Cassandra Query Language Data Modeling The Cassandra Architecture Configuring Cassandra Clients Reading and Writing Data Monitoring Maintenance Performance Tuning Security Deploying and Integrating 個人的には、Chapter 5のモデリングの話(「クエリ」を中心にモデリングすべきである)が参考になったのと、Chapter 6のCassandraのアーキテクチャ、Chapter 9の書き込み、読み込みが内部でどう処理されているかという話が面白かったです。

第7回 ECMA-262 Edition5.1 読書会で発表してきました

月一くらいで開催されている ECMA-262 Edition5.1読書会 に第5回から参加させていただいていて、この度発表する機会をいただきました。 この勉強会は  @takesako さんが翻訳なさった「 ECMA-262 Edition 5.1を読む 」を読み進めていく勉強会で、 僕が今回担当したのは第10条 実行可能コードと実行コンテキストの10.4〜10.6のところです。 第7回 ECMA-262 Edition5.1読書会 from Shou Takenaka 文章だと分りにくいところが色々あったので、クラス図とかオブジェクト図とか描いてまとめてみました。 個人的には10.5の仮引数、関数、arguments、ローカル変数のバインド処理のところが、こんな感じで動いているのか〜って感じで面白かったです。

Gitのブランチ名とステータスをBashのプロンプトに表示する

GitHub Flow なんかを採用していると、ブランチを切り換えることがよくあるので、今どのブランチにいるのか頻繁に確認したくなります。 いちいち git branch で確認するのは面倒なので、僕はこんな感じでプロンプトにブランチ名を表示させています。ついでにワークツリーの状態(更新したファイルがあるか、新規ファイルがあるかどうかなど)も一目でわかるようにしています。 RedHatなプロンプトになっているので、他のスタイルが好きな場合はお好みでPS1をいじればOK。 (ブログで見つけたスクリプトをカスタマイズして使っているのですが、ソースがどこだったのかわからなくなってしまいました。検索しても見つからないので、ページ削除されたのかな?) 2014/11/6編集 元々72行目にあった tput sgr 0 0 を削除しました。 これがあると、vagrant等のシェルでこのスクリプトを読み込んでいる場合にscpができなくなり、provisionなどが行えなくなるという問題が発覚したためです。

ActiveGroongaを使ってみる (2)

今関わっている某プロジェクトでGroongaを採用したいと思って、色々と読んだりいじったりしています。 Railsアプリケーションに組み込みたいと思っているので、ActiveGroongaを使うのがよさそうだと思って試し始めたのですが、リファレンスがまだComing soonでわからないところがたくさんあったりするので、コードを読みながらちまちまと進めていることをまとめておくことにしました。 この検証では Rails 4.1.5 を使っています。別バージョンだとこの方法では動かないかもしれませんのであしからず。 今回はマイグレーションについて書いています。 マイグレーションスクリプトの定義 マイグレーションスクリプトの実行 テーブルスキーマの確認 マイグレーションスクリプトの定義 前回 の手順でSampleモデルを生成すると、db/groonga/migrate ディレクトリにマイグレーションスクリプトが生成されます。 class CreateSamples < ActiveGroonga::Migration def up create_table( :samples ) do |table| table.timestamps end end def down remove_table( :samples ) end end create_tableの中の書き方(何メソッドを呼べばいいのか)がわからなかったのでGitHubの ActiveGroonga と Rroonga の中身を調べたところ、create_table のブロックの引数に渡される table には、Groonga::Schema::TableDefinition のインスタンスが入っている事が判明。 Groonga::Schema::TableDefinitionのメソッド を呼び出してテーブルのスキーマを定義できるようです。 ということで色々なデータ型のカラムを追加してみました。 class CreateSamples < ActiveGroonga::Migration def up create_table( :samples ) do

ActiveGroongaを使ってみる (1)

今関わっている某プロジェクトでGroongaを採用したいと思って、色々と読んだりいじったりしています。 Railsアプリケーションに組み込みたいと思っているので、ActiveGroongaを使うのがよさそうだと思って試し始めたのですが、リファレンスがまだComing soonでわからないところがたくさんあったりするので、コードを読みながらちまちまと進めていることをまとめておくことにしました。 この検証では Rails 4.1.5 を使っています。別バージョンだとこの方法では動かないかもしれませんのであしからず。 今回はインストール〜モデル生成まで書いています。 インストール 設定 データベース作成 モデル作成 インストール まずはgroongaパッケージをインストールします。 ちなみに、パッケージを入れなくてもActiveGroonga gemをインストールした時にソースからビルドしてくれるようですが、結構時間がかかるみたいです(参考: rroongaを最速でインストールするには )。 パッケージをインストールしたらGemfileに以下を追加して bundle install します。 gem "activegroonga" , require: "active_groonga" 設定 config/groonga.yml にデータベース格納先を指定します。例えば下記のような感じ。 2014/9/2 追記 コメントいただきました。自分で作らなくても、後述の bin/rake groonga:create 時に自動的にこのファイルができました。自動生成だとDBのパスが db/groonga/#{RAILS_ENV}/db になるので、パスを変えたい時は自分でこのファイルを用意する、という使い方をすればいいようです。 development: database: "db/groonga/development/db" 次に config/application.rb で ActiveGroonga の railtie を require します。 require "rails/all&quo