商売力開発ブログ

非エンジニアがWebサービスの開発、運営によって商売力をつける記録、その他の雑記

【スポンサーリンク】

JavaScriptのPromiseで処理の順番を制御する

今回はJavaScriptのPromiseについて、重めの処理をする際に順番を制御するのに利用したので説明します。

データ読込処理などで処理の順番を制御する

データの読込など時間のかかる処理を行う場合を考えてみます。例えば以下は我々の開発しているプロジェクト管理ツールにExcelのデータをコピーして、ペーストでデータを貼り付けるイメージです。

このままだとペーストした場合に、全ての処理が終わってからブラウザ側のDOMに反映されます。処理に時間がかかるり何もされてないように見えるので、良く考えられる対応は処理の完了前後にデータをロードしているスピナーのようなイメージ画像などを表示する対応です。処理の開始時にイメージ画像を表示、表示後にペースト処理、ペースト処理の完了後にイメージ画像を消去するといった流れです。
このようにJavaScriptで処理の完了を待ち、その順番を制御するのにPromiseを利用します。

Promiseについて

Promiseを使った非同期処理の基本構文はPromiseオブジェクトを作成して、then() でコールバックを登録していきます。then() で setTimeout() を実行しても良いですが、今回はコンストラクタで実行します。

// 1:new Promise()によりPromiseオブジェクトを作成
var promise = new Promise((resolve, reject) => {
    // 3: 非同期処理実行
    setTimeout(() => {
        console.log("対象処理の実行");
        var result="処理結果";
        // 4: 完了時にresolve()を実行、結果を渡すことも可能
        resolve(result);
    }, 500);
});
 
// 2:Promiseオブジェクトにthen()でコールバックを登録
promise.then((result) => {
    // 5:resolve() の引数を渡してコールバック実行
    console.log(result);
});

上記の書き方だと、gulp-uglifyでmin化したときにエラーとなってしまいました。ちょっと調べて解決策がわからなかったのですが、Promiseの引数や then() をfunction形式にして対応することができます。

// 1:new Promise()によりPromiseオブジェクトを作成
var promise = new Promise(function(resolve, reject){
    // 3: 非同期処理実行
    setTimeout(function(){
      console.log("対象処理の実行");
      var result="処理結果";
      // 4: 完了時にresolve()を実行、結果を渡すことも可能
      resolve(result);
    }, 500);
});
 
// 2:Promiseオブジェクトにthen()でコールバックを登録
promise.then(function(result){
    // 5:resolve() の引数を渡してコールバック実行
    console.log(result);
});

上記を基本構文として説明していきます。まず new Promise() でインスタンス化することでpromiseオブジェクトを作成しています。このpromiseオブジェクトには3つの状態があります。

  1. pending:初期状態。成功も失敗もしていません。
  2. fulfilled:処理が成功して完了したことを意味します。コールバック関数内で resolve() が呼ばれます。
  3. rejected:処理が失敗したことを意味します。コールバック関数内で reject() が呼ばれます。

reject() は、明示的に reject() された場合だけでなく、コンストラクタでエラーがスローされた場合に暗黙的にも発生します。この成功の resolve() や失敗の reject() が呼ばれた場合の処理を then() で定義します。then() は上記の基本構文では1つの引数にしてますが、2つの引数をコールバックとして持つことができ、それぞれが成功と失敗に対応します。

promise.then(function(result) {
    console.log(result); // resolve()
}, function(err) {
    console.log(err); // reject()
});

また then() はPromiseオブジェクトを返すので連鎖させてメソッドチェーンにして記述することもできます。このとき値が返されると、その値を指定して次の then() が呼び出されます。

promise.then(function(result){
    // 1回目の処理
    var val=1;
    return val + 2; // returnして次の処理に渡す
}).then(function(val){
    // 2回目の処理
    console.log(val)// 3が表示される
});

then() の2つのコールバックの名前をonFulfilled,onRejectedとすると以下のようになります。

promise.then(onFulfilled, onRejected)

このように then() では成功と失敗の処理を同時に登録することができます。 また、エラー処理だけを書きたい場合には catch() を使用して以下のように記述することができます。

promise.catch(onRejected)

このは catch は以下と同じ意味となります。

promise.then(undefined, onRejected)

チェーンにして記述されている場合に reject() されるとどうなるか。失敗のコールバックを持つ then() または同等である catch() まで処理はスキップされます。その失敗のコールバックが正常に終了すれば、続く成功のコールバックを処理します。また then(onFulfilled, onRejected) と指定した場合、onFulfilled または onRejected が呼び出されますが、両方が呼び出されることはありません。

promise
    .then(func1) // resolve()
    .then(func2,func3) // func1が成功の場合はfunc2を実行、reject()かfunc1が失敗の場合はfunc3を実行
    .catch(func4) // 直前実行のfunc2またはfunc3が失敗の場合のみfunc4を実行
    .then(func5) // func2またはfunc3が成功の場合、または直前実行のfunc4が成功の場合はfunc5を実行
;

今回の対応方法

今回は基本構文を基にコンストラクタで非同期処理を行い、例外処理の中で reject() を明示して対応しました。

promise = new Promise(function(resolve, reject){
    //対処処理の開始前にimageを表示する
    console.log(”スピナー画像の表示”);
    
    //非同期処理
    setTimeout(function(){
        //対象処理
        try{
            //対象処理の実行
            console.log(”対象処理の実行”);
        }catch(e){
            //失敗の場合、reject() を呼び出す
            reject(e);
        }
        //成功の場合、resolve() を呼び出す
        resolve();
    }, 500);
});

promise.catch(function(e){
    //エラー処理
    console.error("エラー:", e.message);
}).then(function(){
    //成功、失敗の共通処理
    console.log(”スピナー画像の非表示”);
});

スピナー画像の対応後のイメージです。

IE11の対応

PromiseはIEでは未対応です。polyfillを読み込むことで対応できます。以下のリンクを参考にして、scriptタグを追加して対応しました。
https://www.promisejs.org/

<script src="https://www.promisejs.org/polyfills/promise-7.0.4.min.js"></script>

まとめ

今回はPromiseを利用しての、処理の順番の制御方法の説明でした。

以上

Laravelのセッション管理にRedisを指定し、AWSのElastiCacheを利用する

今回はLaravelのセッション管理について、Redisを指定しAWSのElastiCacheを利用する方法について説明します。

Laravelのセッション管理方法について

Laravelのセッション管理方法については以下の種類があります。

  • file - セッションはstorage/framework/sessionsに保存されます。
  • cookie - セッションは暗号化され安全なクッキーに保存されます。
  • database - セッションはリレーショナルデータベースへ保存されます。
  • memcached/redis - セッションはスピードの早いキャッシュベースの保存域に保存されます。
  • array - セッションはPHPの配列として保存されるだけで、リクエスト間で継続しません。

初期状態は「file」で既定のパスに保存されます。この設定で問題になるのはウェブサーバが複数台になった場合です。それぞれのウェブサーバのパスでセッションが管理されることになるため、認証が必要なサイトの場合にあるウェブサーバで認証したのに別のウェブサーバに接続した際に再度認証を求められることになりまし、その他セッションに保存した情報が共有されなくなります。

cookie利用時に出た課題

「cookie」を設定した場合、クライアントに暗号化されたクッキーが保存されます。この設定をした場合、Nginx側で「400 Bad Request」のエラーが出るようになりました。クッキーのサイズが原因でNginxの設定で「large_client_header_buffers」を変更すれば発生する頻度が低減できることは確認できましたが、完全に防ぐことできるわけではあありません。セッションの機能を多く使ったつもりはないのですが、「large_client_header_buffers」が既定値のままだとある程度利用するとこのエラーが出ました。将来的にセッションの機能の利用方法を拡張することで、このエラーがより発生する可能性が高くなりそうなので他の方法で対応することにします。

Redisの利用

他の方法として「database」かインメモリ型の「memcached/redis」ですが、今回は「database」より高速な「memcached/redis」を利用します。AWSでは1年間以内であればElastiCacheの無料利用枠がありますので、「redis」をこれで活用することにします。気付いたら無料利用枠が色々広がってます。AWS凄いですね。

ElastiCacheの利用のための設定

Laravelが稼働しているEC2から、ElastiCacheに接続できるようにします。EC2とElastiCacheは同一VPCとして設定していきます。

セキュリティグループの追加

ElastiCacheに設定するセキュリティグループを追加しておきます。作成するときにVPCはEC2と同一のものを指定します。

 

作成したセキュリティグループのインバウンドのルールにRedis用のポート番号を指定します。デフォルトでは「6379」です。ソースに「0.0.0.0/0」を指定するとVPC内で起動した全てEC2からアクセスできます。

ステップ 4: アクセスを許可する - Amazon ElastiCache

ElastiCacheのサブネットグループの追加

ElastiCacheのメニューからサブネットグループを追加します。登録済みのサブネットからVPCに関連するものが選択できます。アベイラビリティーゾーン(以下、AZ)が複数になるようにすることが推奨されています。ElastiCacheの作成するときにレプリケーション数としてノードを複数作成ることがかのうで、それぞれのノードのAZを分散させることで障害に強くなります。

リージョンとアベイラビリティーゾーンの選択 - Amazon ElastiCache

ElastiCacheクラスターの作成

ElastiCacheの作成ボタンからRedisを選択して、作成します。今回はノードのタイプを無料枠の「t2.micro」にして、それ以外はデフォルトの設定のままとします。ポート番号を変更する場合はセキュリティグループの設定も変更して下さい。レプリケーション数は「2」のままとします。

作成ボタンを押した後に数分後にステータスが「available」となれば作成できた状態です。「有効なクラスターモード」としていないのでシャードは「1」です。ノードはプライマリとレプリケーション数の2を足した3となっています。
ちなみにAWSの無料枠はt2.microで750時間/月となってす。これは1ノードが1カ月稼働してる分には無料ですが、複数のノードとなると無料枠を超えることになるのでレプリケーション数には注意しましょう。

作成したクラスターの情報を確認し、プライマリエンドポイントをコピーしておきます。Laravelの設定で使用します。

ノードの状態を見るとAZが自動で振り分けられ複数のAZにノードがある状態となります。現在のロールが「primary」のエンドポイントを確認しておきます。先ほどのプライマリエンドポイントとは違うものとなっています。

「primary」がフェイルオーバーして他のノードが昇格した場合、「primary」のノードは変更され、「primary」のエンドポイントは変更されることになりますが、プライマリエンドポイントはそのままです。プライマリエンドポイントを利用することで、障害発生時もアプリケーション側の設定は変更せずに対応することができるようになります。

Laravelの設定

Laravelの設定として「APPDIR/config/database.php」のRedisに関する内容を確認します。

    'redis'=> [
        'client' => 'predis',

        'default' => [
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'password' => env('REDIS_PASSWORD', null),
            'port' => env('REDIS_PORT', 6379),
            'database' => 0,
        ],

    ],

標準では「client」に「predis」が設定され、「host」などはenvファイルで設定することができるようになっています。

まずpredisのインストールです。composerを利用してpredisをインストールします。以下のコマンドでrequireでインストールできます。

composer require predis/predis

または「composer.json」のrequireにpredis/predisを追加してアップデートします。

composer update

predisのインストールができたら、envファイルの設定です。SESSION_DRIVERには「redis」を設定し、REDIS_HOSTには先のプライマリエンドポイントを指定します。

SESSION_DRIVER=redis
REDIS_HOST="プライマリエンドポイント" REDIS_PASSWORD=null REDIS_PORT=6379

動作確認

Laravelのサイトにアクセスして問題ないか確認します。ノードの状況で接続のカウントなどに反映されていれば、とりあえずの動作は問題ない状態です。

まとめ

今回はLaravelのセッション管理について、Redisを指定しAWSのElastiCacheを利用する方法の説明でした。

以上

【関連するリンク】

www.prj-alpha.biz

AWS Certificate Manager (ACM)のアップデートのメールが来ていたので確認してみた

「Update on Certificate Transparency(CT) with AWS Certificate Manager(ACM)」という件名のメールがAWSから来ていたので確認してみた。

Google Chromeに対応したACMのアップデート

AWSのACMに関する今回のアップデートは、以前に内容を確認したCertificate Transparency(「証明書の透明性」、以下「CT」)に関連してGoogle Chromeに対応するためのものです。
www.prj-alpha.biz
AWSからのメールにも記載していありますが、簡単にGoogle Chromeに対応したACMのアップデート内容を要約すると以下のようになります。

  • Google Chromeでは2018/04/30以降に発行されたSSL証明書では少なくとも2つのCTログに記録がない場合、Google Chrome上でエラーメッセージが表示される可能性があります。
  • これに対応して、ACMで発行したSSL証明書の発行/更新時にCTログに記録するように更新しました。これは2018/04/24から対応しています。

Google Chromeの対応が2018/04/30以降ということで2018/05/01前後にアップデート情報がAWSよりメールで送られています。ACMを利用しているサイトはAWSが対応するので、特に何か作業を行う必要はありません。ただし、CTログにはサブドメインを含むドメイン名が記載されるので、CTログに記載され公開されることで何かしら問題がある場合のみ対応が必要です。

Google ChromeでACMでSSL証明書を発行したサイトを見てみる

ACMで発行したSSL証明書を使用しているサイトをGoogle Chromeでアクセスしてみてエラーメッセージが出るか確認してみます。今回は以下の我々が運営しているウェブサイトで確認してみました。
home.prj-alpha.biz
Google Chromeで表示すると以下のようになりました。


ブラウザのアドレスの部分には「保護された通信」と表示されているので、エラーメッセージが出ることなくAWSの対応が適用され問題なくできているようです。念のためサブディレクトリについても確認しましたが同様に特に問題ありませんでした。
CTログの状況はその提唱者でもあるグーグルが以下で提供しています。
Google Transparency Report
ドメイン名を入力してCTログ数を確認して下さい。
※実際に問題があるサイトの場合、エラーメッセージがGoogle Chrome上でどのような形式で表示されるかは確認できていません。

まとめ

今回はACMのCT対応に関するアップデートついて、Google Chromeで問題ないか確認しました。ACMを使用してSSL証明書の発行している方は、念の為問題がないか確認して下さい。またACMを使用していないサイトでもGoogle Chromeで確認しSSL証明書が問題ないかを確認した方が良いと思われます。
ACM以外のSSL証明書を使用している方は認証局に一応対応状況を確認した方が良いと思います。

以上

ドメインの変更時に、AWSのS3を利用して旧ドメインから301リダイレクトさせる方法

今回は独自ドメインで運用していたウェブサイトのドメイン名を変更した場合の対応を紹介します。
今回はサブドメイン名を変更した状態を想定し、変更前のドメイン名を「旧ドメイン名」としその値を「old.domain.com」、変更後のドメイン名を「新ドメイン名」としその値を「new.domain.com」と記載していきます。

ドメイン名を変更するとどんな影響があるか

これまで運用していたウェブサイトについてドメイン名を変更した場合の対応について考えます。運用サイトのドメイン名の変更作業自体は済んでいるものとします。

まずドメイン名を変更することで一番大きな影響は、旧ドメイン名でリンクした内容が問題になります。ユーザが旧ドメイン名でお気に入りに追加していたり、コンテンツの中に旧ドメイン名で設定されたリンクについて対応が必要になります。対応しないと旧ドメイン名に接続しに行きページが存在しませんという状態になってしまいます。
そしてグーグルの検索結果にも旧ドメイン名で表示されます。
今回はこの部分の対応について考えていきます。

法人などで変更対象のウェブサイトが名刺や会社案内などの印刷物に記載されている場合、刷り直しなどが必要になってくるものもあるでしょう。

対応方針

ドメイン名を変更した場合、旧ドメイン名から新ドメイン名に301リダイレクトさせるのが一般的な対応となります。301リダイレクトについては以下参照して下さい。 

www.prj-alpha.biz

旧ドメインにアクセスしてきたリクエストを新ドメインに301リダイレクトするには、Apacheなどのウェブサーバの設定の変更で対応することができますが、サーバの設定を変更できない場合があります。例えばこのはてなブログなどです。
このようなときに簡単な設定で301リダイレクトする方法を検討してみたいと思います。ドメインを取得する際に利用したドメイン登録サービスでリダイレクトするサービスを提供しているものがあります。ただしそのリダイレクトが301リダイレクトか確認する必要があります。例えばお名前ドットコムではURL転送Plusというサービスがありますが、これは302リダイレクトになっているようです。
AWSの Amazon S3(以下、S3)でリダイレクトができるようなので、今回はそれを利用することにします。

AWSのS3による301リダイレクト

S3はAWSのクラウドストレージサービスですが、静的ウェブホスティングの機能によりストレージにアップロードしたファイルをウェブサーバのように静的コンテンツとしてHTTP でやり取りすることができます。更にこの機能の中にはリダイレクトする機能があります。

S3のリダイレクト機能にはいくつかの方法がありますが、今回は一番簡単なバケットによるリダイレクト設定を行います。バケットの設定のみで、バケットにはファイルは不要です。
旧ドメイン名でS3の静的ウェブホスティングを行い、そこにきたリクエストを新ドメイン名にリダイレクトするように設定します。

S3を設定する

まずはバケットを作成します。名称は旧ドメイン名で作成します。これは独自ドメインでの静的ウェブホスティングするための制約です。

今回は「old.domain.com」となります。その他の設定はいったんなしで作成します。作成が完了した時点で、エンドポイントが確認できます。プロパティのタブを選択して、「Static website hosting」をクリックするとエンドポイントが表示されます。

Route53以外のドメイン登録サービスを利用している場合、独自ドメインのDNSにCNAMEレコードを作成して、このエンドポイントを登録することで独自ドメインでS3バケットが利用できます。

続いて、アクセス権限を設定します。アクセス権限のタブのベケットポリシーをクリックして以下のポリシーを設定して、パブリックユーザにGetObjectの権限を付与してアクセスできるようにします。Resourceの部分は旧ドメイン名となります。

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddPerm",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::old.domain.com/*"]
    }
  ]
}

この状態で保存するとパブリックアクセス権が付与されたことが明示されます。

最後にリダイレクトの設定を行います。プロパティのタブを選択して、「Static website hosting」をクリックして「リクエストをリダイレクトする」を選択し、リダイレクト先に新ドメイン名を入力します。http/httpsを指定したい場合はプロトコルに設定します。

これで旧ドメインへのリクエストはバケットの設定により、全て新ドメインのホストにリダイレクトされることになります。このリダイレクトの設定はサブディレクトリも含まれます。

その他のリダイレクト設定は公式ページを参照して下さい。

docs.aws.amazon.com

301リダイレクトの設定ができているか確認する

設定ができた後に問題ないか確認しましょう。一番簡単なのはブラウザで旧ドメイン名をURLに入力して新ドメイン名に変更されるか確認する方法です。

この他に以下のサイトでは301リダイレクトされているかステータスコードが確認することができます。

HTTP Header Response Status Codes Check Tool

URLに旧ドメイン名を入力して、Checkボタンを押してしばらく待った後に以下のように301と結果が出ていれば問題ありません。

新ドメイン名 - 301 Moved Permanently
旧ドメイン名 - 200 OK

サブディレクトリが問題ないかもこちらで確認することができます。

ドメイン名に変更に関連して、その他にやること

ドメイン名に変更に関連してURLを保持しているシステムなどの設定も変更が必要になります。SEO関連のツールではグーグルの Google Analytics 、 Search Console はきっちり変更しましょう。特に Search Console はグーグルの検索結果のインデックスに影響しますので必ず対応しましょう。

www.prj-alpha.biz

まとめ

今回はAWSのS3を利用しての301リダイレクトの紹介でした。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

 

LaravelのマイグレーションでPKの設定時に注意する

今回はPHPフレームワークの一つのLaravelの中から、データベースのマイグレーションでのプライマリキー(以下、PK)の設定の注意事項について説明します。ユニークとインデックスから説明し、その後にPKについて説明します。

マイグレーションファイルでのユニークとインデックスの設定

以下はLaravelのマイグレーションファイルでのユニークとインデックスの設定例です。

    public function up()
    {
        Schema::create('samples', function (Blueprint $table) {
            $table->string('column_name1',5);
            $table->string('column_name2',5);
            $table->string('column_name3',5);
            $table->string('column_name4',5);
            $table->string('column_name5',5);
            $table->timestamps();
            
            //ユニーク設定
            $table->unique(['column_name1','column_name2','column_name3','column_name4']);
            //インデックス設定
            $table->index(['column_name2','column_name3','column_name4','column_name5']);
        });
    }

テーブルの定義の後にユニークとインデックスの設定をしています。基本的な設定方法はこの書き方になりますが、これを実行すると以下のようなエラーとなります。

$ php artisan migrate

SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name 'samples_column_name1_column_name2
_column_name3_column_name4_unique' is too long (SQL: alter table `samples` add unique `samples_column_name1
_column_name2_column_name3_column_name4_unique`(`column_name1`, `column_name2`, `column_name3`, 
`column_name4`))

これは自動で付与されるカラム名を連結したユニーク名称「samples_column1_column2_column3_column4_column5_unique」が長すぎるのが原因で発生しています。インデックスの設定についても同様の名称が設定されてエラーとなります。このため以下のようにして、名称を設定をします。

            //ユニーク設定
            $table->unique(['column_name1','column_name2','column_name3','column_name4'],'UNIQUE_NAME');
            //インデックス設定
            $table->index(['column_name2','column_name3','column_name4','column_name5'],'INDEX_NAME');

名称を設定することでエラーがなくなります。名称が設定されているかは以下のSQLで確認します。

select table_name,index_name,column_name,seq_in_index from information_schema.statistics
where table_name = 'samples';

結果は以下のようになっています。

table_name index_name column_name seq_in_index
samples UNIQUE_NAME column_name1 1
samples UNIQUE_NAME column_name2 2
samples UNIQUE_NAME column_name3 3
samples UNIQUE_NAME column_name4 4
samples INDEX_NAME column_name2 1
samples INDEX_NAME column_name3 2
samples INDEX_NAME column_name4 3
samples INDEX_NAME column_name5 4

マイグレーションファイルでのPKの設定

続いてはLaravelのマイグレーションファイルでのPKの設定例です。

    public function up()
    {
        Schema::create('samples', function (Blueprint $table) {
            $table->string('column_name1',5);
            $table->string('column_name2',5);
            $table->string('column_name3',5);
            $table->string('column_name4',5);
            $table->string('column_name5',5);
            $table->timestamps();
            
            //PK設定
            $table->primary(['column_name1','column_name2','column_name3','column_name4']);
        });
    }

これを実行すると以下のようなエラーとなります。

$ php artisan migrate

SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name 'samples_column_name1_column_name2
_column_name3_column_name4_primary' is too long (SQL: alter table `samples` add primary key `samples_column
_name1_column_name2_column_name3_column_name4_primary`(`column_name1`, `column_name2`, `column_name3`
, `column_name4`))

PK設定についてもユニークやインデックスと同じようにカラム名を連結した名称をつけるように動作しているようです。通常、PK設定の場合は「PRIMARY」となるのですが、この自動で設定された名称が原因でエラーとなります。この対応として、ユニークやインデックスと同じように名称を設定することで回避することができます。

            //PK設定
            $table->primary(['column_name1','column_name2','column_name3','column_name4'],'DUMMY_NAME');

SQLの結果は以下のようになっています。設定した「DUMMY_NAME」は出てきません。

table_name index_name column_name seq_in_index
samples PRIMARY column_name1 1
samples PRIMARY column_name2 2
samples PRIMARY column_name3 3
samples PRIMARY column_name4 4

ちなみに、以下のように「'PRIMARY'」として設定して実行しましょう。

            //PK設定
            $table->primary(['column_name1','column_name2','column_name3','column_name4'],'DUMMY_NAME');

すると以下のようなエラーとなります。これは「PRIMARY」はインデックス名称としては使用できないためです。

$ php artisan migrate

SQLSTATE[42000]: Syntax error or access violation: 1280 Incorrect index name 'PRIMARY' 
(SQL: alter table `samples` add primary key `PRIMARY`(`column_name1`, `column_name2`, `column_name3`
, `column_name4`))

PKの設定では通常は名称の設定は不要ですが、エラーとなった場合はダミーの名称を設定することで回避することができます。ここに注意してマイグレーションファイルを設定しましょう。

まとめ

今回はLaravelのマイグレーションのPK、ユニーク、インデックスの設定を説明しました。

以上

【関連するリンク】 www.prj-alpha.biz www.prj-alpha.biz www.prj-alpha.biz www.prj-alpha.biz

301リダイレクトと302リダイレクト

今回は運用していたウェブサイトのドメイン名を変更した場合、変更前のドメインから変更後のドメインへリダイレクトの対応をすることが多いですが、そのリダイレクトのt対応について説明します。

ステータスコードとリダイレクト

301リダイレクト、302リダイレクトなどと言われる際の最初の3桁の数字はHTTPステータスコードのことを示しています。HTTPステータスコードとは以下になります。

HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードで、RFC 2616、RFC 7231等によって定められている。
(Wikipediaより引用)

「404 Not found」とかの「404」もこのステータスコードの一つです。

またウェブサイトにおけるリダイレクトとは以下になります。

ウェブサイトにおけるリダイレクト(英:redirect)とは、ウェブサイトの閲覧において、指定したウェブページから自動的に他のウェブページに転送されること。URLリダイレクト(URL redirection)とも言われる。
(Wikipediaより引用)

ドメイン変更を例にするとリダイレクトを設定することで、ユーザが 変更前のドメインのURLに接続した場合に自動で変更後のURLに転送することで、常に新しいURLに接続させることができます。

301/302のステータスコードの違い

リダイレクトする際のステータスコードから、「301リダイレクト」と「302リダイレクト」と呼ばれたりしますが、リダイレクトの内容でどちらにするか検討します。

  • 301:恒久的な変更
  • 302:一時的な変更

301リダイレクト

恒久的に変更された場合はこのステータスコードを使用します。この301リダイレクトの使用例としてグーグルは以下のような場合を提示していました。

  • サイトを新しいドメインに移動し、できるだけスムーズに移行を行いたい場合
  • ユーザーが複数の異なる URL を介してサイトにアクセスする場合
  • 2 つのウェブサイトを結合し、無効になった URL へのリンクが正しいページにリダイレクトされるようにしたい場合

support.google.com

ドメイン変更は正しく恒久的な変更となりますので、301リダイレクトを用います。
グーグルの提供する「Search Console」ではウェブサイト毎にグーグル検索結果でのパフォーマンスを監視・管理することができます。ウェブサイトのドメインが変更された場合、この「Search Console」でも監視・管理するウェブサイトのアドレスを変更して引き継ぐことが可能ですが、変更できる条件として301リダイレクトで動作していることがあります。この「Search Console」の変更により、変更後のサイトに変更前のサイトインデックス登録を移行しますので、SEO対策上では大きな意味を持ちます。このことも考慮して恒久的な変更の場合は301リダイレクトするようにしましょう。

302リダイレクト

一時的に変更された場合はこのステータスコードを使用します。一定期間だけメンテナンス画面にリダイレクトさせたいときなどが使用例です。

302リダイレクトの場合、グーグルの検索エンジンはリダイレクト後のページではなく、リダイレクト前のページを評価し続けます。ある程度の期間が長くなる場合はSEO対策上は302リダイレクトを避ける方が良さそうです。

301リダイレクトの設定はどの位の期間まで継続させるか

301リダイレクトは、ドメイン変更など恒久的な変更に対して、変更前へのURLへのアクセスを変更後の新しいURLへ転送するための設定であることは理解できたかと思います。この設定はどの位の期間まで継続させるのが良いでしょうか。
グーグルが新しいサイトやURLをフルに認識するには6ヶ月程はかかる場合があるようです。「Search Console」の変更リクエストの説明にも180日間は検索結果を自動で新しいサイトにリダイレクトするとあります。また変更前のURLにアクセスしようとするユーザーも十分に発生する可能性があるでしょう。
これらを踏まえると最低でも1年間は継続させておくことが良さそうで、可能であればできるだけそのままにしておくのが良いとのことです。

まとめ

今回はドメイン名を変更した場合などに対応するリダイレクトの説明でした。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

ガントチャート作成ツールのタイプ別の使い方

ガントチャートを作成するツールには様々なものがありますが、タイプを別けて説明します。ガントチャートで管理される対象をプロジェクトと呼ぶこととします。プロジェクトは一定期間など期限のある活動で何らかの終了条件があるものとします。

ガントチャートの作成ツールのタイプ

ガントチャートの作成ツールはいくつもありますが、大きく2種類に別けることができます。①直接入力型②積上げ型と命名してそれぞれの特徴や使い方、有効な利用方法を説明していきます。

またガントチャートを構成する行はタスク、チケットなどと色々な呼び方がありますが、アクティビティという表現で統一します。

①直接入力型

直接入力型とは、一覧表形式の入力欄に登録していくと、主にその右側にその入力内容に対応したチャートができる、ガントチャートを直接作成するタイプのツールです。代表例はMicrosoft Projectです。Excelで作成されたものもこのタイプということになります。我々の開発しているProject-Alphaもこのタイプです。

入力管理

このタイプでは、ガントチャートの更新を行うのはプロジェクトの管理者など一部のメンバーに限定して運用することが望ましい場合が多いです。
一覧表形式となっているため更新可能なメンバーは、全てのアクティビティについて編集可能となります。そのため誰でも更新できるようになっていると、自身の担当以外など予期せぬところを間違って編集してしまったりする可能性があるので、管理者など一部のメンバーが責任をもって管理した方が良いでしょう。またExcelなどではファイル共有機能で同時に編集することもできますが、同時で複数人で編集していると前後関係がおかしくなったりと意図しない結果になることもあります。

アクティビティに関連する特徴

アクティビティは管理者が登録するので、ある程度統一された粒度で管理する運用が可能となります。必要に応じて一部は細かい粒度で管理するといったこともあるでしょう。
管理者一人で更新する運用の場合、アクティビティの数が多いとステータスの変更など更新作業に多くの時間を割かれることになりますが、細かくすることで工数や進捗管理の精度が上がります。この辺りのバランスを考慮してガントチャート上でどの粒度で管理するか、プロジェクトの内容や性質、管理者の能力や性格に合わせて変わってくることになります。内容や期間にもよりますが200行を超えた辺りから苦しくなり始め、300行を超えるとガントチャート上での運用がかなり厳しいイメージです。この厳しいとは、「管理ができなくなる」ということだけでなく、「管理はできてるが負荷が高くなる」ということも含みます。
ここで「ガントチャート上で」と記載していますが、プロジェクトを管理するためのツールはガントチャートだけではないので、適切なツールを併用して使用していけば良いのです。運用が厳しく感じたら、管理方法を見直すタイミングかもしれません。大事なのは全てをガントチャートで管理することではなく、プロジェクトを成功に導くことです。

報告資料としてのガントチャート

このタイプを選択する理由の一つとして、プロジェクトのステークホルダーに報告する資料としてガントチャートを作成するという場合があります。これはガントチャートが視認性に優れていて、ステークホルダーが誰でもアクティビティの順序や進捗状況、スケジュールを理解し易くすることができるためです。ただ行数が多くなるにつれて視認性はどうしても下がりますので、必要に応じて他の資料と合わせて報告すると良いでしょう。
報告資料としての用途の場合、以下のようなことがポイントとなります。

  • アクティビティはステークホルダーが分かる・求める粒度にする。細かくし過ぎると煩雑で確認しにくいと言われ、抽象化しまとめ過ぎると分かりにくいと言われることがあります。
  • お客様との会議体などで報告する必要があり、誰でも参照できる状態を求められることがあります。具体的には紙に印刷できることやExcel化、PDF化してファイルを配布するように求められることがあります。
  • 報告資料用と実際のアクティビティ管理用のガントチャートを共通で利用できるか。共通利用できると、効率的な運用をすることが可能です。逆に二重管理のような状態になってしまうと、負荷が高まります。

有効な利用パターン

  • アクティビティがある程度パターンが決まっているプロジェクトでは、過去のプロジェクトの設定をそのまま利用することができるので有効です。プロジェクトの内容により変更が必要な部分だけアクティビティの追加・修正・削除すれば良いので効率的に準備をすることができます。
  • ガントチャート上で管理が必要なアクティビティの数が多すぎないプロジェクト(例えば100個程度など)は、ガントチャートの視認性を活かせるので有効です。プロジェクトの状況をガントチャートを介して素早く理解することができます。

②積上げ型

積上げ型とは、ガントチャートを構成するアクティビティを一つ一つ個別に登録していき、登録されたアクティビティをまとめて表示することでガントチャートとして表現することができるタイプのツールのことです。代表例はRedmineです。
このタイプのツールでは、ガントチャートは数ある機能の一つとして提供されており、アクティビティの管理に関連して様々な機能を持つプロジェクト管理ツールとして提供されていることが多いです。

入力管理

このタイプでは、アクティビティを登録できるのはプロジェクトに参加しているメンバー全員などで運用することが多いです。自分の担当や関連するアクティビティを各自が登録できるようにする運用イメージです。ただし外部の組織のメンバーなどで、ツールにアクセスする権限がない場合は代行して入力することになります。
各アクティビティにはファイルを添付したりコメントしたりと、アクティビティ毎に個別に情報を追加する機能を備えてるツールもあります。

アクティビティに関連する特徴

アクティビティは色々なメンバーが登録するので、アクティビティを管理する上で一定のルールを策定して運用するのが一般的です。
アクティビティに対して集約するための分類情報を紐付けたり、親となるアクティビティを紐付けて登録することが可能となっているツールが多く、それらを集約し、まとめて表示することでガントチャートとして表示する仕組みになっています。
プロジェクトが進んでいく中で、必要になったアクティビティをどんどん追加していくことが多く、細かい作業単位で登録していくことで作業漏れをなくしつつ着実に進捗を管理をしていく運用が多いです。

ガントチャート以外の様々な機能

このタイプはプロジェクト管理ツールの中の一つの機能としてガントチャートでの表示機能が備えられていることが多いです。ガントチャートはコアな機能ではなく、周辺機能の一つという扱いです。
プロジェクト管理ツールとして、ガントチャート以外では以下のような機能があることが多いです。

  • アクティビティをカンバン方式・カレンダー形式・タイムラインなど様々な形式で表示することができる。
  • アクティビティ以外にToDoリストが管理できる。
  • メンバー間でチャットやメッセージなどでコミュニケーションすることができる。
  • プロジェクト毎にWiki機能がある。

これらは代表的な機能ですが、プロジェクト管理ツールによって他にも様々な機能を有しているものがありますので、活用できる機能がないか確認してみて下さい。

有効な利用パターン

  • 参加するメンバーの多いプロジェクトで、そのメンバー全員がプロジェクト管理ツールを利用することができる状況で有効です。全員が利用できるので、必要な情報共有を素早くすることができます。
  • アクティビティの追加頻度が高く、細かい単位で大量のアクティビティを管理していくプロジェクトの場合に有効です。

ただし、このタイプではプロジェクト管理として様々な機能を提供しているツールが多いので、それらを含めてどの機能をどのように利用するかによって効果が変わってきます。導入するにあたって影響を受ける業務範囲やメンバーを確認の上、有効に利用できるようにしましょう。

まとめ

今回はガントチャート作成ツールを①直接入力型と②積上げ型というタイプ別にして、それぞれの特徴を中心に説明しました。ガントチャートを利用した方が良い場合はこちらの情報で検討にお役立て下さい。 

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz 

www.prj-alpha.biz

home.prj-alpha.biz

 

【スポンサーリンク】